Что такое OAuth?
Вы наверняка слышали об опасностях разглашения своих паролей и почему этого делать не стоит. Существуют различные протоколы, предназначенные для вашей защиты и которые избавят вас от необходимости повторного ввода ваших паролей или учетных данных. Когда веб-сайт требует ввести пароль для получения доступа, он может воспользоваться техникой под названием OAuth для того, чтобы упростить задачу.
Цель этой статьи – показать вам, как веб-сайт или приложение принимают запросы на вход от пользователей, которые их посещают. У этих платформ есть необходимые полномочия? Есть ли у них право подтверждать вашу личность и получать доступ к некоторым вашим данным от вашего имени? OAuth объясняет весь этот процесс и помогает его упростить. Прочитайте статью до конца, чтобы узнать, как онлайн-проверки стали автоматизированными и как так получилось, что для их завершения требуется всего один клик.
Что такое OAuth?
OAuth – это протокол авторизации открытого стандарта, который можно добавить в приложения, чтобы позволить пользователям получать безопасный доступ к их платформе. Например, с помощью этого протокола вы можете указать приложению Facebook разрешить ESPN.com доступ к вашим сообщениям и обновлениям в социальных сетях без обязательного раскрытия ваших учетных данных. Такой доступ позволяет существенно снизить риск. Если на ESPN.com вдруг произойдет утечка данных, то информация, которой вы владеете в Facebook, будет защищена.
OAuth работает, не обмениваясь паролями с другими платформами. Вместо этого он просто отправляет им маркеры авторизации. Этот маркер используется для подтверждения личности пользователя. Это ключевая стратегия, которой пользуются клиенты и поставщики услуг. Проще говоря, эта концепция представляет собой протокол аутентификации, который позволяет платформам и поставщикам услуг взаимодействовать, не выдавая при этом свои пароли.
Примеры OAuth
Один из распространенных примеров протокола OAuth связан с большинством устройств Android. Когда вы покупаете смартфон Android, то вам необходимо войти в свою учетную запись электронной почты, чтобы получить доступ к большинству функций телефона.
Когда вы вошли в свою электронную почту в телефоне, то вам понадобиться некоторая информация для доступа к другим приложениям или веб-сайтам. Принципы OAuth позволяют пользователям мгновенно обмениваться своими учетными данными электронной почты с платформой. Вам не потребуется вводить пароль, но при этом веб-сайт позволит вам аутентифицироваться и получить доступ.
Существует множество других примеров и вариантов использования протокола OAuth, которые демонстрируют его концепцию. И это при условии, что вы можете обмениваться своими учетными данными для получения информации на разных платформах без повторного ввода пароля.
Хорошим примером здесь может послужить ситуация, когда вас перенаправляют на другой веб-сайт, и вы получаете сообщение с текстом «Эй, вы хотите получить доступ к нашему сайту с учетными данными другого сайта?» Давайте условно назовем веб-сайт, запрашивающий доступ пользователя, получателем, а платформу, на которой вы в данный момент вошли в систему, — отправителем. Когда вы пытаетесь войти на сайт-получатель, вам необходимо будет узнать, заходите ли вы на сайт под тем же именем, что и на сайте-отправителе.
Facebook – один из наиболее распространенных примеров платформ, которые используют данный протокол. Когда вы используете приложение на Facebook, оно запросит доступ к информации и фотографиям вашего профиля. В таком случае Facebook является отправителем ваших данных для получения доступа и изображений. Приложение здесь является получателем, и как пользователь вы намерены пользоваться услугами принимающей платформы. Нажимая кнопку «Разрешить», вы предоставляете получателю доступ к вашим изображениям, а OAuth существенно упрощает весь этот процесс.
Некоторым вашим умным домашним устройствам, таким как телевизору, системе безопасности, тостеру и т.д., требуется вход в систему, чтобы вы могли управлять ими через браузер или мобильное устройство. Эти устройства работают на, так называемой, конфиденциальной авторизации OAuth, и они надежно хранят ваши учетные данные. Таким образом, вам не требуется вводить свои учетные данные на различных терминалах веб-сайта.
Как работает OAuth?
Реальность такова, что OAuth был разработан с целью фокусировки внимания на авторизации, а не на аутентификации. Авторизация предполагает получение разрешения на выполнение определенных действий. А вот аутентификация предполагает доказательство того, то вы являетесь лицом, которое имеет необходимый доступ к информации, защищенной в профиле. OAuth не запрашивает аутентификацию пользователя, а просто разрешает доступ к другим приложениям и ресурсам.
Хороший способ рассмотреть принцип работы этого протокола – это провести аналогию с ключом камердинера. Такой ключ предназначен для того, чтобы дать камердинеру доступ к управлению вашим автомобилем, но при этом он не обязательно позволит ему открыть багажник. Токен OAuth предназначен для использования в качестве служебного ключа для вашего смарт-устройства. Как пользователь вы можете контролировать информацию, которая будет использоваться на разных платформах. Вы можете вручить ключ камердинера каждому получателю, но у них все равно не будет ключа полного доступа или доступа к конфиденциальных данным, которые скрыты в профиле.
В абсолютно любой транзакции OAuth участвуют 3 основные стороны: пользователь, отправитель и получатель. Эти 3 стороны в шутку можно назвать любовным треугольником OAuth. Мы рассмотрим несколько простых шагов для того, чтобы проиллюстрировать то, как OAuth обеспечивает защиту аутентификации для пользователей на разных платформах.
- Шаг 1: пользователь показывает свое намерение получить доступ
- Шаг 2: получатель получает разрешение. Учетные цифровые идентификационные данные будут отправлены вместе с этим разрешением, которые будут использоваться для выявления подделки и проверки источника запроса на права доступа.
- Шаг 3: пользователь перенаправляется к поставщику услуг или отправителю.
- Шаг 4: пользователь дает разрешение.
- Шаг 5: получатель получает маркер доступа.
- Шаг 6: получатель получает доступ к защищенному ресурсу.
SAML vs OAuth
Многие люди очень легко могут указать на сходства между SAML и OAuth, но их концепции все же очень разные. SAML, также известный как язык разметки утверждений безопасности, представляет собой альтернативный стандарт проверки личности пользователя, который многие организации используют для поддержки функций системы единого входа (SSO). SAML – это функция, позволяющая организациям контролировать тех, кто отвечает за корпоративные ресурсы.
Между SAML и OAuth есть множество различий. SAML использует XML для отправки сообщений, а OAuth – технологию JSON. OAuth разработан для того, чтобы упростить работу с мобильными устройствами, а SAML – для обеспечения повышенного уровня безопасности. Последнее различие является основным. OAuth в основном полагается на API. Именно поэтому многие мобильные приложения, современные веб-сайты, игровые приставки и Интернет вещей используют данный протокол. Как правило, OAuth предлагает пользователям больше возможностей. Чтобы провести аутентификацию пользователя, SAML сбрасывает cookie сессию в браузере пользователя, которая позволяла человеку получать доступ к определенным веб-страницам. Такой вариант отлично подходит для краткосрочного доступа, но не очень подходит для случаев, когда вам необходимо входить в сеть многократно.
OpenID vs OAuth
Если говорить простым языком, то OpenID используется для аутентификации, а OAuth – для авторизации.
OpenID поддерживает интегрированную аутентификацию. Это означает, что он поддерживает сторонние приложения для поддержки и аутентификации пользователей при попытке использовать уже имеющиеся учетные записи. В то же время, OAuth был разработан для того, чтобы вам не приходилось вводить свои учетные данные для входа в сторонние приложения.
Оба протокола могут использоваться для выполнения похожих задач, но это вовсе не означает, что они взаимозаменяемы. OpenID обеспечивает подтверждение личности, в то время как OAuth имеет более общее направление использования. Когда клиент использует OAuth, сервер выдает маркер доступа третьей стороне, этот маркер используется для доступа к защищенному ресурсу, а источник проверяет этот маркер. Здесь еще стоит обратить внимание на то, что личность владельца маркера не проверяется.
Сравнение
SAML 2.0
OAuth2
OpenID Connect
Открытый стандарт аутентификации и авторизации
Что такое OAuth-авторизация?
OAuth-авторизация — это технология, с помощью которой пользователь авторизуется на вашем сайте с помощью своего аккаунта Mail.ru. Это увеличивает конверсию случайных посетителей в постоянных, и ваша аудитория растет — любой пользователь Mail.ru потенциально может стать вашим. Технология основана на протоколе OAuth 2.0.
Чтобы воспользоваться OAuth Почты:
- Зарегистрирутесь на Mail.ru.
- Создайте приложение.
- Настройте приложение для разных платформ.
- Сконфигурируйте кнопку входа.
- Вставьте готовый код кнопки на ваш сайт или в приложение.
Если вы знакомы с технологией и предпочитаете работать по API, воспользуйтесь технической документацией.
Правила использования данных, получаемых для авторизации пользователя, смотрите в пользовательском соглашении.
Authorization code
Для получения кода авторизации (authorization code) Приложение партнера должно осуществить вызов ресурса /v2/oauth/authorize .
Также получение пары Access и Refresh Token возможно через swagger: текущий тестовый контур, новый тестовый контур.
Host и полный url для вызова ресурса на тестовом и промышленном контурах см. в разделе URL для вызова API СберБизнес ID.
Направления взаимодействия, описанные в разделе, выделены на схеме красным.
Параметры запроса
При запросе ресурса /v2/oauth/authorize используются параметры, полученные при регистрации приложения Партнера.
| Параметр | Тип | Описание |
|---|---|---|
| scope | Query | Обязательный параметр. Область сведений (разрешения), до которых требуется получить доступ Приложению Партнера. Должен содержать обязательный параметр «openid». Через пробел должны быть указаны атрибуты (claim) и ресурсы, полученные при регистрации приложения. Значения переданные в параметре scope сравниваются со значениями согласованными при регистрации приложения |
| response_type | Query | Обязательный параметр. Всегда должен содержать значение «code». Авторизация по СберБизнес ID поддерживает только authorization code flow протокола OAuth 2.0 |
| client_id | Query | Обязательный параметр. Уникальный идентификатор Приложения Партнера, полученный при регистрации приложения |
| redirect_uri | Query | Обязательный параметр. Ссылка на ресурс (конечную точку) Приложения партнера, на которую будет передан код авторизации и перенаправлен браузер пользователя после успешной авторизации. Значение переданное в параметре redirect_uri сравнивается по маске со значением, полученным при регистрации приложения. Пример: При регистрации приложения указана маска для redirect_uri : https://example.ru/auth/login Если при запросе кода авторизации будет указан адрес: https://example.ru , то такое значение не пройдет проверку, т.к. отсутствует часть обязательных path параметров указанных при регистрации; https://example.ru/auth/login/register , то такое значение пройдет проверку, т.к. совпадает с зарегистрированным. При этом расширение path параметров не влияет на проверку |
| state | Query | Обязательный параметр. Параметр для предотвращения CSRF-атак. Значение State должно быть защищено от подбора и храниться таким образом, чтобы его не мог изменить никто, кроме Приложения партнера. Рекомендуется использовать идентификатор сессии клиента в сервисе партнера или один из его производных (например, хэш этого идентификатора), при этом может использоваться любой другой механизм генерации случайного значения достаточной длины для предотвращения подбора. В общем случае оптимально использовать строку длиной не менее 36 символов с проверкой регистра, без использования специальных символов. Полные требования к значению state см. в спецификации rfc6749. Для повторного запроса это значение должно заменяться новым |
| nonce | Query | Обязательный параметр. Параметр служит для защиты от replay-атак, то есть для предотвращения обработки одного и того же запроса несколько раз. Значение Nonce должно быть защищено от подбора и храниться таким образом, чтобы его не мог изменить никто, кроме Приложения Партнера. Рекомендуется использовать случайное значение, сохраняемое в сессии клиента в сервисе партнера. Для повторного запроса это значение должно заменяться новым. В общем случае оптимально использовать строку длиной не менее 10 символов с проверкой регистра, без использования специальных символов. Полные требования к значению nonce см. в спецификации Open ID Connect |
| code_challenge | Query | Необязательный параметр. Параметр в соответствии с надстройкой PKCE над протоколом OAuth 2.0. Должен быть уникальным для каждого вызова ресурса /authorize . См. правила формирования параметра в PKCE. Подключение настройки согласуется с менеджером при регистрации приложения. Рекомендуется к использованию, т.к. увеличивает безопасность подключения |
| code_challenge_method | Query | Необязательный параметр. Связанный с code_challenge параметр. Заполняется в соответствии со спецификацией PKCE. Если указан, то всегда должен содержать значение «S256». Параметр «plain» не поддерживается. Если передан параметр code_challenge , то параметр code_challenge_method должен обязательно присутствовать |
Вызов ресурса должен осуществляться только с использованием экранирования специальных символов.
Пример запроса без экранирования
Request URL: https://edupir.testsbi.sberbank.ru:9443/ic/sso/api/v2/oauth/authorize?scope=openid PAY_DOC_RU inn email&response_type=code&client_id=999999&state=a18821dc752640c0a1dda57a17c122fb&nonce=02e5d3d2-b2a8-4a87-be43-af7ffb8649f2&redirect_uri=https://example.ru Request Method: GET Пример запроса с экранированием
Request URL: https://edupir.testsbi.sberbank.ru:9443/ic/sso/api/v2/oauth/authorize?scope=openid%20PAY_DOC_RU%20inn%20email&response_type=code&client_id=999999&state=a18821dc752640c0a1dda57a17c122fb&nonce=02e5d3d2-b2a8-4a87-be43-af7ffb8649f2&redirect_uri=https%3A%2F%2Fexample.ru Request Method: GET Параметры ответа
После успешной авторизации пользователя, СберБизнес ID перенаправит ( http-code = 302 ) браузер пользователя на адрес, который был указан в параметре redirect_uri и добавит следующие query параметры:
| Параметр | Тип | Описание |
|---|---|---|
| code | Query | Значение кода авторизации. Формируется произвольно в формате UUID (случайное значение) плюс «1» или «2» через дефис, например, CD6A56FD-A9C7-4152-AA1D-FA57E550F6AC-2 . Срок жизни кода авторизации составляет 120 секунд |
| state | Query | Значение параметра state, полученного при вызове ресурса /v2/oauth/authorize . Полученный параметр state должен быть проверен Приложением Партнера на соответствие значению, указанному при вызове ресурса /oauth/authorize . Если значения не совпадают, обработка должна быть немедленно прекращена |
Пример ответа
HTTP/1.1 302 Found Location: https://example.ru?code=f710576d-7263-4ec6-a01b-8404aca2850d-1&state=a18821dc752640c0a1dda57a17c122fb Коды возврата
Если запрос на ресурс /oauth/authorize был выполнен некорректно и допущены ошибки при формировании параметров, то в зависимости от типа допущенной ошибки пользователю будет показана страница ошибки СберБизнес ID или браузер пользователя будет перенаправлен ( http-code = 302 ) на адрес, который был указан в параметре redirect_uri с добавлением следующих query параметров:
| Параметр | Тип | Описание |
|---|---|---|
| error | Query | Код возникшей ошибки |
| error_description | Query | Описание возникшей ошибки |
| state | Query | Значение параметра state, полученного при вызове ресурса /v2/oauth/authorize . По значению параметра state и коду полученной ошибки Приложение Партнера может понять, какой вызов был осуществлен некорректно |
Приложение Партнера должно обработать полученные параметры и уведомить пользователя о действиях, которые ему необходимо выполнить.
Перечень исключений, сообщения о которых передаются на адрес Приложения Партнера:
| Значение параметра error | Значение параметра error_description | Описание причины возникновения |
|---|---|---|
| invalid_request | Missing parameters: | В параметрах запроса кода авторизации отсутствует хотя бы один из обязательных параметров: response_type , state , scope |
| unsupported_response_type | Response_type not supported | В параметрах запроса кода авторизации указан неправильный response_type |
| invalid_scope | Scope ‘openid’ is required | В параметре scope отсутствует обязательный параметр openid |
| invalid_request | Invalid code challenge | В параметре code_challenge передано значение не отвечающее требованиям протокола PKCE |
| invalid_request | Transform algorithm required | Передан параметр code_challenge , но не указан code_challenge_method |
| invalid_request | Transform algorithm not supported | В параметр code_challenge_method указано значение отличное от S256 |
| invalid_scope | Too many scopes requested | Вызов осуществлен на ресурс предыдущей версии ( /v1/oauth/authorize ) и в параметре scope передано более одного дополнительного значения scope |
| invalid_scope | Invalid scope param value | Вызов осуществлен на ресурс предыдущей версии ( /v1/oauth/authorize ) и в параметре scope передано незарегистрированное значение scope |
| invalid_scope | Invalid scope | В параметре scope передано незарегистрированное значение scope |
| invalid_scope | Scope PAYMENT_SUBSCRIPTION is required | В параметре scope должен присутствовать параметр payment_subscription . Особенности использования параметра payment_subscription , см. в Подключение подписки |
| invalid_scope | Scope PAYMENT_SUBSCRIPTION is forbidden | Параметре scope не может содержать параметр payment_subscription . Особенности использования параметра payment_subscription , см. в Подключение подписки |
| invalid_request | Code challenge required | В параметрах запроса кода авторизации должны быть указаны параметры code_challenge и code_challenge_method |
Для части возникающих исключений невозможно осуществить перенаправление пользователя обратно на сайт Приложения Партнера.
В таких случаях пользователю будет показана форма сообщения об ошибке:
Для дополнительной диагностики в url адреса страницы будет добавлен параметр error, в котором будет указана причина возникшей ошибки.
Следующие причины и коды могут приводить к перенаправлению на страницы ошибки:
| Код причины | Описание причины |
|---|---|
| invalid_params | В параметрах запроса присутствуют повторяющиеся query параметры |
| redirect_uri_is_absent | В параметрах запроса отсутствует обязательный параметр redirect_uri |
| client_id_is_absent | В параметрах запроса отсутствует обязательный параметр client_id |
| bad_client_id | В параметрах указан незарегистрированный client_id |
| client_blocked | В параметрах указан заблокированный client_id |
| invalid_redirect_uri | В параметрах запроса параметр redirect_uri не совпадает со значением указанным при регистрации приложения |
Подключение Подписки
Если Приложение Партнера зарегистрировано как сервис, работающий по подписочной модели, то при запросе кода авторизации через ресурс /v2/oauth/authorize необходимо учитывать следующие правила и условия.
Существует две модели работы сервиса по подписке:
- без пробного периода;
- с пробным периодом.
Если Приложение Партнера зарегистрировано по модели:
- без пробного периода, то при запросе кода авторизации /v2/oauth/authorize в параметре scope обязательно должен быть указан атрибут PAYMENT_SUBSCRIPTION ;
- с пробным периодом, то при запросе кода авторизации /v2/oauth/authorize , если в параметре scope атрибут PAYMENT_SUBSCRIPTION будет:
- отсутствовать, то у пользователя будет запрошено согласие на подключение сервиса без подписки;
- указан, то у пользователя будет запрошено согласие на подключение сервиса с подпиской, т.е. клиент будет переведен на модель оплаты «по подписке».
Бесшовный переход из СберБизнес в Приложение Партнера
Приложение Партнера может быть зарегистрировано в системе СберБизнес и размещено в разделе Продуктов и Услуг Банка и его Партнеров.
В этом случае пользователи, работающие в системе СберБизнес, могут подключать и/или переходить в приложение Партнера, не вводя дополнительных логинов и паролей.
Для этого при регистрации Приложения Партнера необходимо передать сведения о ресурсе Приложения Партнера, на который будет перенаправлен пользователь.
При вызове ресурса Приложения Партнера в query параметры будут добавлены следующие значения:
Параметр Описание loginDCB В значении true. Признак означает, что пользователь осуществил переход в Приложение Партнера из системы СберБизнес userType Может принимать значение: WEB — для пользователей, использующих SMS-подтверждение; Token — для пользователей, осуществляющих аутентификацию с помощью устройства защиты. callbackPort Значение порта для пользователей, осуществляющих аутентификацию с помощью устройства защиты. Эти параметры необходимы для корректного формирования хоста для запроса Authorization Code и существенного упрощения пользовательского опыта в части перехода в сервис Партнера.
Пример вызова Приложения Партнера и ответного запроса кода авторизации для пользователя использующего СМС подтверждения
СберБизнес осуществит вызов Приложения Партнера с параметрами:
https://example.ru/authorization/sbbid?loginDCB=true&userType=WEBЕсли Приложение Партнера получило вызов с указанными параметрами, то вызов ресурса /v2/oauth/authorize должен осуществляться на стандартный хост и домен СберБизнесID соответствующего контура (см. URL для вызова API СберБизнес ID). В примере указан промышленный контур:
https://sbi.sberbank.ru:9443/ic/sso/api/v2/oauth/authorize?scope=openid%20PAY_DOC_RU%20inn%20email&response_type=code&client_id=999999&state=a18821dc752640c0a1dda57a17c122fb&nonce=02e5d3d2-b2a8-4a87-be43-af7ffb8649f2&redirect_uri=https%3A%2F%2Fexample.ruПример вызова Приложения Партнера и ответного запроса кода авторизации для пользователя использующего устройство защиты
СберБизнес осуществит вызов Приложения Партнера с параметрами:
https://example.ru/authorization/sbbid?loginDCB=true&userType=Token&callbackPort=28016Если Приложение Партнера получило вызов с указанными параметрами, то вызов ресурса /v2/oauth/authorize должен осуществляться на http://localhost с указанием порта полученного из параметра callbackPort:
http://localhost:28016/ic/sso/api/v2/oauth/authorize?scope=openid%20PAY_DOC_RU%20inn%20email&response_type=code&client_id=999999&state=a18821dc752640c0a1dda57a17c122fb&nonce=02e5d3d2-b2a8-4a87-be43-af7ffb8649f2&redirect_uri=https%3A%2F%2Fexample.ruПорядок получения VPNKeyTLS токена для работы на тестовом контуре описан в разделе Получение VPNKeyTLS токена для тестового контура.
ПАО Сбербанк использует cookie для персонализации сервисов и удобства пользователей.
Вы можете запретить сохранение cookie в настройках своего браузера.Документация
Наши продукты
Юридические документы© 1997–2024 ПАО СберБанк. Генеральная лицензия на осуществление банковских операций от 11 августа 2015 года. Регистрационный номер — 1481
OAuth 2.0 — основы понятным языком
Рассмотрим типичную ситуацию. Вы нашли в интернете интересный ресурс (пусть это будет к примеру портал онлайн-курсов coursera.org), но чтобы им полноценно воспользоваться, нужно создать личный аккаунт и войти в него. Вас не особо радует необходимость «стопятьсот» раз проходить нудную процедуру регистрации: придумывать логин и пароль, вводить личные данные, потом как-то это все запоминать.
Детям из Мариуполя нужно 120 ноутбуков для обучения — подари старое «железо», пусть оно работает на будущее Украины
Тем не менее, скрепя сердце, вы нажимаете «Войти» и в открывшейся форме обнаруживаете вдруг решение в виде кнопок входа через аккаунты социальной сети. Выбираете любимую соцсеть, например Facebook. Кликаете, после чего вас перебрасывает на форму авторизации. Там вы указываете свои логин и пароль в Facebook. Далее вам предложат разрешить доступ приложению ресурса к вашему аккаунту. Подтверждаете. И все — вы каким-то магическим образом вошли на ресурс, используя регистрационные данные от Facebook. Никаких новых паролей, имен пользователя, заполнения прочих полей не потребовалось.
Для реализации подобных сценариев (а также множества аналогичных) и предназначен стандарт OAuth 2.0.
Что такое OAuth 2.0?
OAuth 2.0 (RFC 6749) является открытым фреймворком авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.
Курс Мікросервісна архітектура.
програма, яка допоможе опанувати головні принципи розробки мікросервісної архітектури, щоби ви могли проєктувати незалежні сервіси, а потім інтегрувати їх в одну систему. Практики буде багато.
История создания
OAuth появился в ноябре 2006 года, во время разработки Блейном Куком (англ. Blaine Cook) протокола OpenID для сервиса микроблогов Twitter. Совместно с Крисом Мессиной (англ. Chris Messina) он искал способ использования OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Дэвидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также нескольких других проприетарных протоколов авторизации, и пришли к заключению о необходимости в новом, универсальном и открытом протоколе.
В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В ее работе приняли участие сотрудники компаний Google и AOL. Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. 15 апреля 2009 года Twitter предложил пользователям решение, позволяющее делегировать сторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Twitter» и основано на OAuth.
В апреле 2010 года был выпущен информационный документ RFC 5849, посвященный стандарту OAuth. В 2010 году началась работа над новой версией протокола OAuth 2.0. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, а использование носителя токена регламентировано в RFC 6750. Вторая версия была несовместима с первой.
Для создания OAuth 2.0 был ряд оснований. Во-первых, нужно было упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трех методов получения токена (уникального идентификатора) для авторизации — для веб-приложений, настольных клиентов и мобильных клиентов — фактически все три способа были слиты в один. В-третьих, протокол оказался плохо масштабируемым.
В результате в новый протокол было внесено несколько важных изменений:
- Упрощенная подпись. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
- Короткоживущие токены с долговременной авторизацией. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
- Разделение ролей. За авторизацию и за предоставление доступа к API могут отвечать разные серверы.
На данный момент OAuth 2.0 используется большим количеством ведущих сервисов, таких как Google, Instagram, Facebook, «ВКонтакте» и другие.
Курс Product Management.
Програма розрахована на тих, хто хоче розпочати свою кар’єру як Product Manager з нуля і тих, хто вже працює в IT і хоче перейти в цю спеціалізацію.
Отличие от OpenID
Часто можно услышать такой вопрос. А зачем нужен OAuth, если существует OpenID? Хотя OAuth и OpenID имеют много общего, между ними есть принципиальная разница:
- OAuth — протокол авторизации, то есть позволяет предоставить права на использование некоторого ресурса (например, API какого-либо сервиса). При этом в общем случае нельзя определить, кто в настоящий момент пользуется правами.
- OpenID является средством аутентификации: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдает. Какими правами обладает пользователь, прошедший аутентификацию, определяет сторона проводящая аутентификацию.
Как работает OAuth 2.0?
Стандарт OAuth 2.0 определяет следующие четыре роли :
- владелец ресурса — сущность, обладающая правом на выдачу доступа к защищенным ресурсам. В случае если владелец является человеком, его называют конечным пользователем;
- сервер ресурсов — сервер, содержащий защищаемые ресурсы и обладающий возможностью получения и формирования ответа на запросы к защищаемым ресурсам посредством использования маркера доступа;
- клиент — приложение, осуществляющее доступ к защищенным ресурсам от имени владельца. Термин «клиент» явно не определяет какое-либо конкретное исполнение (будь то сервер, персональный компьютер или мобильное приложение);
- сервер авторизации — сервер, осуществляющий выпуск маркеров доступа для клиентских приложений после успешной аутентификации и авторизации владельца ресурсов.
Общая схема взаимодействия выглядит следующим образом:
В описанном выше примере взаимодействуют два приложения (клиент, сервер авторизации совмещенный с сервером ресурсов) и конечный пользователь.
Це хороший спосіб розвитку вашої кар’єри в IT-індустрії. Після проходження курсу Mate гарантує вам офер мрії.
Таким образом имеется:
- Конечный пользователь (вы).
- Клиент (приложение сайта на котором мы хотим авторизоваться coursera.org).
- Сервер авторизации (приложение социальной сети Facebook, аккаунт, которой мы хотим использовать). В данном случае он же будет являться и сервером ресурсов, но вообще это могут быть разные приложения.
- Клиент запрашивает у конечного пользователя прохождение авторизации на сервере авторизации (в приведенном примере, это когда пользователя перенаправляют на страницу логина Facebook, затем запрашивают разрешение на доступ из приложения клиента).
- После того как конечный пользователь авторизовался, клиент получает грант авторизации. (Фактически грант авторизации клиенту выдает сервер авторизации, после того как конечный пользователь авторизовался и подтвердил выдачу запрашиваемых клиентом прав.)
- Клиент запрашивает у сервера токен доступа. При этом клиент предоставляет некоторые идентификационные данные о себе и грант авторизации от пользователя. Токен доступа представляет собой альтернативу логину и паролю, имеет ограниченное время действия и связан с определенными ограничениями прав. Отметим, что клиент должен быть предварительно зарегистрирован на сервере авторизации, чтобы можно было его идентифицировать.
- Если подлинность клиента подтверждена и разрешение на авторизацию действительно, сервер авторизации создает токен доступа для клиента и передает его. Авторизация завершена.
- Клиент использует токен доступа для аутентификации на сервере авторизации.
- Клиент получает доступ к необходимым ресурсам (читает данные аккаунта пользователя Facebook и создает на ее основе свою учетную запись).
Итак, чтобы запросить токен доступа, клиент получает авторизацию от владельца ресурса. Разрешение выражается в виде гранта авторизации ( authorization grant ), который клиент использует для запроса токена доступа ( access token ). OAuth определяет четыре типа предоставления:
- код авторизации ( authorization code ),
- неявный ( implicit ),
- учетные данные владельца ресурса,
- учетные данные клиента.
Также предоставляется механизм расширения для определения дополнительных типов грантов. Рассмотрим их подробнее.
Код авторизации (авторизация для приложений, имеющих серверную часть)
Код авторизации (авторизация для приложений, имеющих серверную часть).
- Клиент инициирует поток, направляя пользовательского агента (интернет-браузер) к конечной точке авторизации. Клиент включает свой идентификатор клиента, запрос прав, локальное состояние и URI перенаправления, на который сервер авторизации отправит пользовательского агента, после того как только доступ будет предоставлен (или запрещен).
- Сервер авторизации аутентифицирует владельца ресурса (через пользовательский агент) и предоставляет или отклоняет запрос клиента на доступ.
- Предполагая, что владелец ресурса предоставляет доступ, сервер авторизации перенаправляет пользовательский агент обратно клиенту, используя URI перенаправления, предоставленный ранее (в запросе или во время регистрация клиента). В URI перенаправления сервер включает код авторизации.
- Клиент запрашивает токен доступа у сервера авторизации, отправляя код авторизации полученный на предыдущем шаге. Делая запрос, клиент аутентифицируется на сервере авторизации. Ранее клиент должен был зарегистрироваться на этом сервере авторизации. Сервер авторизации при регистрации выдает клиенту секретный ключ. Клиент включает этот ключ в запрос токена доступа, чтобы пройти аутентификацию на сервере.
- Сервер авторизации аутентифицирует клиента, проверяет код авторизации и гарантирует, что полученный URI перенаправления соответствует URI, используемому для перенаправления клиента в шаге (3). Если это действительно так, сервер авторизации предоставляет токен доступа и при необходимости токен обновления.
Пример
Примеры приводятся для API Mail.Ru. Перенаправляем браузер пользователя на страницу авторизации:
> GET /oauth/authorize?response_type=code&client_id=464119& redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1.1 > Host: connect.mail.ru
client_id и client_secret — значения, полученные при регистрации приложения на платформе. После того, как пользователь выдаст права, происходит перенаправление на указанный redirect_uri :
Используем полученный code (код авторизации) для получения токена доступа, выполняя запрос с сервера:
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_code&client_id=464119&client_secret=deadbeef&code=DoRieb0y& redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 < HTTP/1.1 200 OK < Content-Type: application/json
Обратите внимание, что в последнем запросе используется поле client_secret , который в данном случае хранится на сервере приложения, и подтверждает, что запрос не подделан.
В результате последнего запроса получаем токен доступа ( access_token ), время его жизни ( expires_in ), тип ключа, определяющий как его надо использовать, и токен обновления. Полученные данные можно использовать для доступа к защищенным ресурсам.
> GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo& sig=. HTTP/1.1 > Host: appsmail.ru
Неявный (Авторизация полностью клиентских приложений)
Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена кода авторизации на токен доступа.
- Клиент инициирует поток, направляя пользовательского агента к конечной точке авторизации. Клиент включает в запрос свой идентификатор клиента, права, локальное состояние и URI перенаправления, на который сервер авторизации отправит пользовательский агент, как только доступ будет предоставлен (или запрещен).
- Сервер авторизации аутентифицирует владельца ресурса (через пользовательский агент) и предоставляет или отклоняет запрос клиента на доступ.
- Когда доступ предоставлен владельцем ресурса, сервер авторизации перенаправляет пользовательский агент обратно клиенту, используя URI перенаправления, указанный ранее. URI перенаправления включает токен доступа в параметрах.
- Пользовательский агент следует инструкциям перенаправления, создает запрос к клиентскому сервису, размещенному в интернете, а данные параметров сохраняет локально.
- Клиентский ресурс, размещенный в интернете, возвращает веб-страницу (обычно документ HTML со встроенным скриптом), способный получить полный доступ к URI перенаправления, включая данные параметров, и извлечь токен доступа.
- Пользовательский агент выполняет скрипт, предоставленный клиентским ресурсом, локально и извлекает токен доступа.
- Пользовательский агент передает токен доступа клиенту.
Пример
Открываем браузер со страницей авторизации:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Host: connect.mail.ru
После того, как пользователь выдаст права, происходит перенаправление на стандартную страницу-заглушку.
Здесь приложение должно перехватить последний редирект, получить из адреса acess_token и использовать его для обращения к защищенным ресурсам.
Учетные данные владельца ресурса (Авторизация по логину и паролю)
Авторизация по логину и паролю представляет простой POST -запрос, в результате которого возвращается токен доступа. Данная схема вставлена в стандарт для общности и рекомендуется к применению тогда, когда другие варианты авторизации не доступны.
Пример
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&[email protected]& password=qwerty < HTTP/1.1 200 OK < Content-Type: application/json
Учетные данные клиента
Клиент может запросить токен доступа, используя только свои учетные данные, например когда запрашивает доступ к защищенным ресурсам, находящимся под его контролем. Данный вариант тривиален и подробно рассматриваться не будет.
Восстановление предыдущей авторизации
Обычно, токен доступа имеет ограниченный срок годности. Чтобы не заставлять пользователя проходить авторизацию после истечения срока его действия, во всех перечисленных выше вариантах в дополнение к токену доступа может возвращаться еще токен обновления. По нему можно получить новый токен доступа с помощью HTTP-запроса, аналогично авторизации по логину и паролю.
Пример
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8 < HTTP/1.1 200 OK < Content-Type: application/json
Зачем нужен Authorization Code
Возникает вопрос: почему бы сразу не отдать клиенту токен доступа, с которым можно обращаться к ресурсам? Зачем сначала получать код авторизации, а потом его обменивать на токен доступа? Вроде бы лишний шаг.
Дело в том, что это безопаснее. Канал между приложениями (клиентом и сервером ресурсов) безопасный ( back сhannel ). А канал запросов, проходящих через браузер ( front channel ), — нет. Код авторизации проходит через браузер: он возвращается в url при перенаправлении обратно на клиент. Для обращения к ресурсам прошедший через браузер код авторизации не очень подходит. Его относительно легко может перехватить злоумышленник. Поэтому он заменяется на токен доступа, пересылаемый через безопасный канал ( back сhannel ). Кроме того, без секрета клиента ( client-secret , который также передается по back сhannel ) токен доступа не получить, что обеспечивает дополнительную безопасность.
Зачем нужен refresh токен?
Допустим, кто-то завладел вашим токеном доступа и получил доступ к защищенным данным. Именно поэтому у токенов есть срок годности. У токена доступа он обычно небольшой — от нескольких секунд до нескольких дней, у токена обновления — много больше. Так вот: доступ к данным у злоумышленника будет до тех пор, пока токен доступа не «протухнет», то есть недолго.
Допустим, этот некто завладел также и токеном обновления и получил новый токен доступа. Вам будет достаточно разлогиниться и залогиниться заново. Все старые токены станут недействительными или удалятся (зависит от реализации). После этой процедуры вы получаете новые токены и можете спокойно продолжить работу, а злоумышленник со старыми токенами остался с носом.
Преимущества и недостатки OAuth 2.0
Из плюсов протокола OAuth 2.0 можно выделить следующее:
- Обращение к ресурсам происходит по HTTP/HTTPS с указанием токена в заголовках. Это позволяет использовать OAuth практически в любых решения: мобильных и десктоп-приложениях, сайтах и даже в плагинах для браузеров.
- Возможность авторизации пользователя.
- Популярность — большинство компаний используют его в своих API.
- Простота реализации и большое количество литературы.
- Наличие готовых решений, которые можно изменять под свои нужды.
Из минусов:
- Нет единого установленного формата, вследствие чего на каждый сервис нужно иметь отдельную реализацию.
- При аутентификации иногда приходится делать дополнительные запросы для получения даже минимальной информации о пользователе. Решается использованием jwt -токена, но далеко не все сервисы его поддерживают.
- При краже токена у злоумышленника на какое-то время появляется доступ к защищенным данным. Для минимизации данного варианта можно использовать токен с подписью.
Итоги
Итак, OAuth 2.0 — это гибкая технология для делегирования прав доступа к приложениям. Сценариев использования OAuth 2.0 огромное количество, это может быть как упрощенный вход на сторонние сайты, так и автоматизация чтения статистики из соцсети или выполнения удаленных вычислений. Что угодно, что требует сквозной авторизации для доступа к своим ресурсам.
В целом, OAuth 2.0 исправляет недостатки OAuth 1.0, но имеет ряд своих недостатков. На данный момент он все еще находится в развитии. Следующая ожидаемая версия стандарта — OAuth 2.1.
Закрепить озвученный материал можно в этом тематическом видео:
Курс Мікросервісна архітектура.
програма, яка допоможе опанувати головні принципи розробки мікросервісної архітектури, щоби ви могли проєктувати незалежні сервіси, а потім інтегрувати їх в одну систему. Практики буде багато.