OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
15 мая 2021 · 7 минуты на чтение
В этой статье рассмотрим историю возникновения и схему работы. Разберемся в чем отличие OAuth 2.0 от OpenID Connect и что такое SSO.
Спонсор поста
История возникновения OAuth
Авторизацией через социальные сети никого уже не удивишь. Нажимаешь кнопку соц сети, вжух и ты авторизовался на новом сайте. Сайт получил твоё ФИО, фотку и прочие данные. Но так было не всегда.
В «каменном веке» интернета все было проще. Вы просто давали свой логин и пароль от одного сервиса другому, чтобы тот вошел в вашу учетную запись и получил любую необходимую ему информацию.
OpenID Connect. Теория
На заре становления Facebook просил у пользователей логин и пароль от Gmail аккаунта, чтобы отправить контактам приглашение. Такой подход имеет большую проблему: логин и пароль дают полный доступ к сервису. Поэтому был разработан стандарт OAuth.
С помощью этого стандарта вы позволяете приложению считать данные или использовать функции другого приложения от вашего имени, не сообщая ему свой пароль. Класс!
OAuth 1.0 не используется. Забудьте о нем. Используйте OAuth 2.0
Главным недостатком OAuth 1.0 была слишком большая сложность данной версии.
Начнем разбор OAuth 2.0 с ролей. Всего есть 4 роли:
- Владелец ресурса.
- Клиент.
- Сервер ресурсов.
- Авторизационный сервер.
Далее мы рассмотрим каждую из ролей.
Владелец ресурса
Ресурсом являются данные, например ФИО, фотография, ваши сообщения в соц сетях, и прочее. Владелец ресурса это пользователь. При межсерверном общении владельцем ресурса может быть один из серверов.
Сервер ресурсов
На сервере ресурсов лежат ваши данные. В случае с примером выше ваши контакты Gmail это ресурс, а лежат они на серверах Gmail.
Клиент
Клиент это сервис, которому требуется доступ к вашим ресурсам. Например, Facebook требуется доступ к контактам Gmail.
Авторизационный сервер
В данном примере он принадлежит Google, так как он хранит ваши данные.
Стандарт не запрещает вам объединить Сервер ресурсов и Авторизационный сервер
Базовая схема протокола
OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров.
Вернемся к нашему примеру про Facebook и Gmail. На анимации ниже, я постарался схематично изобразить, как реализовать этот пример правильно с помощью Oauth2. Стоит учитывать, что у Google есть свой сервер авторизации, который отвечает за авторизацию на любом сервисе Google. Поэтому Gmail только хранит ресурсы, но не отвечает за авторизацию.
Аутентификация: OAuth2.0 и OpenId Connect
Весь смысл в том, что Клиент должен получить каким-то образом от авторизационного сервера access_token . Способов этих четыре, о них мы поговорим дальше. Используя этот access_token Клиент может использовать его в запросах к Серверу ресурсов, чтобы получать какие-то данные.
Помимо access_token Авторизационный сервер может выдавать также refresh_token . Это токен, который позволяет запросить новый access_token без участия Владельца ресурсов. Время жизни у такого токена намного больше access_token и его потеря гораздо серьезнее.
Вернемся к базовой схеме. Авторизационный сервер должен знать про каждого клиента, который делает к нему запрос. То есть, каждый клиент должен быть зарегистрирован. Зарегистрировав клиента мы получаем client_id и client_secret и обязаны передавать, как минимум client_id в каждом запросе.
Не все клиенты могут гарантировать сохранность client_secret , поэтому он есть не у всех. Например, SPA без бэкенда, теоретически достать оттуда можно что угодно.
Существует возможность регистрировать клиентов динамически: RFC 7591 и RFC 7592.
Рандомный блок
Способы получения Access Token
Всего есть 4 способа:
- По авторизационному коду (Authorization Code Grand). Самый сложный и самый надежный способ.
- Неявно (Implicit)
- По логину и паролю пользователя (Resource Owner Password Credential). Только для безопасных клиентов, заслуживающих полного доверия.
- По данным клиента (Client Credentials). Получаем токен по client_id и client_secret .
Client Credentials
Начнем разбор с самой простой схемы. Этот способ придуман для межсерверного взаимодействия. У нас есть два сервера API1 и API2, и им надо как-то общаться.
- API 1 идет в авторизационный сервер передает туда client_id и client_secret .
curl —request POST —url ‘https://YOUR_DOMAIN/oauth/token’ —header ‘content-type: application/x-www-form-urlencoded’ —data grant_type=client_credentials —data client_id=YOUR_CLIENT_ID —data client_secret=YOUR_CLIENT_SECRET —data audience=YOUR_API_IDENTIFIER
2. Взамен API 1 получает access_token , с помощью которого может обратиться к API 2.
3. API 1 обращается к API 2.
curl —request GET —url https://api2.com/api —header ‘authorization: Bearer ACCESS_TOKEN’ —header ‘content-type: application/json’
4. API 2 получает запрос с access_token и обращается к авторизационному серверу для проверки действительности переданного токена (RFC 7662).
Resource Owner Password Credential
Эта схема не рекомендуется к использованию! В стандарте так и написано, если вы никакие другие схемы не можете сделать, то используйте эту.
- Владелец ресурсов передает свой логин и пароль Клиенту.
- Клиент отправляет Авторизационному серверу логин и пароль клиента, а так же свой client_id и client_secret .
curl -d «grant_type=password» -d «client_id=3MVG9QDx8IKCsXTFM0o9aE3KfEwsZLvRt» -d «client_secret=4826278391389087694» -d «username=ryan%40ryguy.com» -d «password=_userspassword__userssecuritytoken_» https://as.com/oauth2/token
3. Если предоставленные пользователем учетные данные успешно аутентифицированы, сервер авторизации вернет ответ application/json , содержащий access_token :
Authorization Code Grand
Этот способ рекомендуемый. Используйте его, и только если это невозможно, посмотрите на другие способы. Исключением является межсерверное общение.
Является одним из наиболее распространённых типов разрешения, поскольку он хорошо подходит для серверных приложений, где исходный код приложения и секрет клиента не доступны посторонним.
В случае OIDC также имеется стандартный способ, с помощью которого Клиент может запросить дополнительную информацию о пользователе от Сервера авторизации, например, адрес электронной почты, используя access_token .
Заключение
Подведем итог. OAuth 2.0 это простой протокол авторизации, основанный на HTTP, что дает возможность применять его практически на любой платформе. Он имеет хорошую документацию, и большинство крупных площадок его поддерживают. Так что если вы решили использовать этот протокол в своем проекте — это хороший выбор.
Источник: struchkov.dev
Аутентификация с помощью открытого стандарта OpenID
Всем привет! Наверняка каждый из нас зарегистрирован на огромном количестве сайтов, но иногда становится лень заводить очередной аккаунт, заполняя различные формы и отвечая на вопросы капчи. Есть ли выход из этой ситуации?
Аутентификация с помощью OpenID — это хороший инструмент, позволяющий владельцам сайтов значительно упростить процедуру входа пользователей в учётную запись. При этом пользователям не потребуется вводить свои данные для регистрации.
Провайдеры OpenID в прошлом получили широкое распространение, в их число входили такие крупные компании, как Яндекс, Google, Mail.ru, Yahoo. Со временем, каждый из провайдеров один за другим стали прекращать свою работу по протоколам OpenID 1.0 и OpenID 2.0, предлагая более безопасные механизмы авторизации на других сайтах.
OpenID — это открытый стандарт децентрализованной системы аутентификации, предоставляющей пользователю возможность создать единую учётную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов, используя услуги третьих лиц.
Актуальным на данный момент является третье поколение OpenID-технологии с дополнительными механизмами для надёжного шифрования и цифровой подписи, которое представляет собой аутентификационную надстройку над протоколом авторизации OAuth 2.0.
Новое поколение технологии имеет название OpenID Connect и позволяет сайтам проверить подлинность пользователя на основе аутентификации, выполненной сервером авторизации, а также получать базовую информацию о профиле пользователя.
OpenID Connect — это надстройка над протоколом авторизации OAuth 2.0 для проверки личности пользователя на основе аутентификации, выполненной авторизационным сервером.
Организациям, которые хотят обеспечить гарантию и подтвердить соответствие своего способа авторизации стандарту OpenID Connect, требуется пройти сертификацию в некоммерческой организации OpenID Foundation. Сертифицированные партнёры получают право размещать на своём сайте специальный знак:
Среди международных интернет-компаний, прошедших сертификацию OpenID, можно выделить Google, Yahoo, Microsoft, PayPal, Oracle, IBM и многие другие. В российском сегменте крупные компании проигнорировали возможность сертификации, но всё же предлагают своим пользователям API для авторизации на основе открытого протокола OAuth 2.0, в некоторых случаях с учётом требований OpenID Connect.
Делегирование OpenID
Владелец доменного имени может использовать его в качестве синонима (алиаса) к уже существующему OpenID-идентификатору, полученному у любого провайдера OpenID — эта процедура называется делегированием OpenID идентификатора. Вы также можете использовать домен сайта в качестве OpenID.
Существует несколько способов реализации делегирования: сертифицированные провайдеры, серверы, а также внешние библиотеки (на PHP, JavaScript, Python и других языках) — все они представлены в документации для разработчиков на официальном сайте.
Раньше мне доводилось пользоваться услугами популярного на тот момент провайдера myOpenID. Достаточно было зарегистрироваться у провайдера и добавить на свой сайт несколько мета-тегов, а для авторизации на других сайтах, поддерживающих вход с помощью OpenID, — указать свой домен и подтвердить разрешение на доступ.
К сожалению, провайдер myOpenID закрылся 1 февраля 2014 года.
Прекращение его работы, по словам основателя, связано с массовым распространением социальных сетей и почтовых сервисов, предлагающих свои методы аутентификации. Остаётся выбирать другого провайдера OpenID или использовать внешние библиотеки. А вы используете OpenID для авторизации на сайтах?
Источник: webliberty.ru
Что такое OpenID? Четыре Потрясающих Провайдера
Что такое OpenID? Согласно OpenID.net : OpenID — это бесплатный и простой способ использовать единую цифровую идентификацию в Интернете. С одним OpenID вы можете войти на все ваши любимые сайты и забыть об онлайн-оформлении документов! Вау, это звучит здорово.
OpenID — отличная идея. Одно место для входа! Представьте, что вам не нужно запоминать ваше имя пользователя и пароль для множества сайтов, на которые вам нужно войти. Как только вы зарегистрируетесь у провайдера OpenID, как один из приведенных ниже, вам нужно будет просто ввести URL-адрес OpenID на страницу входа на сайт поддержки; и если вы еще не проходили аутентификацию у своего провайдера OpenID, вам будет предложено войти в систему, а если вы уже прошли аутентификацию, вы войдете на сайт.
OpenID также помогает с передачей на сайт такой информации, как имя, местоположение, значки профиля и т. Д. Это помогает в том, что вам не нужно повторно вводить эту информацию столько, сколько вы использовали для каждого отдельного сайта, на котором вы зарегистрировались.
Основным недостатком OpenID является то, что если ваше имя пользователя и пароль были украдены или фишинговыми, то все ваши зарегистрированные сайты станут целями. В то время как некоторые провайдеры OpenID пытаются облегчить это (с помощью проверки изображения или двухфакторной аутентификации ), большинство не делает этого.
Ниже приведен список предлагаемых OpenID-провайдеров, а также краткое резюме и плюсы и минусы каждого:
MyOpenID
MyOpenID управляется компанией под названием JanRain, которая была одним из первых, кто внедрил и продвигал услуги OpenID. Лидер в отрасли, но и небольшая компания. Ищите их, которые будут приобретены в будущем.
Плюсы : широко используемый поставщик. Позволяет настроить настраиваемый URL-адрес OpenID, например openid.yourdomain.com. Основной сторонник стандарта OpenID.
Минусы : компания не «большая», поэтому у них непроверенный послужной список.
Думаешь, у тебя нет OpenID? Google недавно присоединился к множеству поставщиков OpenID, предлагая OpenID для всех учетных записей Google. Итак, если у вас есть адрес Gmail, у вас уже есть OpenID! Посетите страницу их учетной записи, войдите в систему и получите URL-адрес OpenID для регистрации на сайтах, совместимых с OpenID.
Плюсы: у многих людей уже есть доступ к аккаунту Google, Google — стабильная компания с опытом безопасности.
Минусы: Google знает все.
ClaimID
ClaimID — это поставщик OpenID, который имеет больше, чем просто OpenID. Вы можете «требовать» свои URL-адреса и сохранять их на странице профиля. После этого вы можете использовать свой URL-адрес ClaimID (который также служит вашим URL-адресом OpenID) для входа на сайты OpenID. ClaimID отличается от других поставщиков тем, что они предоставляют вам страницу «профиля», на которую вы можете отправлять других людей. Вы также можете импортировать изображения из Flickr, ссылки с Del.icio.us и многое другое.
Плюсы: один из наиболее удобных для потребителей поставщиков OpenID, имеется страница профиля.
Минусы: Сайт, похоже, все еще находится в стадии бета-тестирования. Непроверенный послужной список.
Verisign Labs PIP
Verisign Labs Personal Identity Provider — это сервис OpenID от известной фирмы по обеспечению безопасности. Их обслуживание «простое», что, на мой взгляд, хорошо. Кроме того, уникальной особенностью Verisign PIP является возможность использования двухфакторной аутентификации с вашим логином openID, что дополнительно защищает доступ к вашим веб-сайтам. Для получения дополнительной информации о настройке см. Мой пост об интеграции двухфакторной аутентификации . Они также предоставляют бесплатный аддон Firefox, который автоматически заполнит ваш URL OpenID на веб-сайтах; и дает визуальное представление, если ваш логин OpenID в настоящее время действителен.
Плюсы: только двухфакторный провайдер, которого я нашел, известная охранная компания. Бесплатный OpenID Firefox аддон.
Минусы: OpenID URL трудно запомнить.
Полный список поставщиков OpenID см. По адресу: http://openid.net/get-an-openid/.
Таким образом, вы используете OpenID для консолидации ваших логинов. В настоящее время основным недостатком является то, что не многие сайты принимают OpenID в качестве действительного имени входа. Некоторые основные из них, Blogger , WordPress и другие [ см. Полный список здесь ], появятся в сети.
Сначала обратите внимание на медленное принятие, а затем «переломный момент», за которым последуют многие сайты. Судя по указанным мною признакам, вскоре мы увидим широкое распространение OpenID среди блогов, новостных сайтов и многого другого. В конце концов, и после того, как технология будет проверена, мы можем увидеть, что банки и другие сайты с высоким уровнем безопасности принимают OpenID.
Источник: gadgetshelp.com