что такое домен аутентификации

Доменная (LDAP) аутентификация в Codeigniter

Статья ориентирована на начинающих Codeigniter-щиков, таких как я.

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

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

Допустим, что CI уже установлен и настроен. Кстати, на одном из западных сайтов, доступно много хороших и исчерпывающих видео уроков по настройке и использованию Codeigniter-а.

Добавим библиотеку и конфигурационный файл

Конечно, существуют некоторые функции в самом PHP, но использовать их не всегда рационально. За основу возьмем библиотеку adLDAP. В ней есть все необходимое и даже больше.

Первым делом создадим конфигурационный файл, например adldap.php и положим его в \system\application\config\

Далее необходимо добавить библиотеку. Но как сделать так, что бы ей можно было пользоваться в CI, как остальными? За нас это уже сделал один программист, и предоставил для общественного пользования (онутверждает, что лицензия не нарушена). Ее мы и добавим в \system\libraries\ и назовем, например Adldap.php.

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

Напишем небольшой код авторизации

Сделать это проще простого.
Во-первых, создадим форму для ввода логина и пароля:

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

Для более тонкой настройки нужен еще один параметр для проверки — группа (Active Directory). Назовем ее, например Web_Group, и добавим нужных нам пользователей:

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

//Вытаскиваем и проверяем прошел или нет пользователь авторизацию
if ($this->session->userdata(‘is_logged_in’) == true) <

echo «Доступ к данным открыт»;

Теперь осталось только дописать функцию уничтожения сессии (Logout):

function logout() <
$this->session->sess_destroy();
redirect();
>

Спасибо за внимание.

UPD: нашел еще одну интересную LDAP библиотеку.

Источник

Особенности аутентификации контроллера домена с использованием двух разных сертификатов

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

Схожая проблема возникла в одном из наших проектов, где заказчику необходимо было организовать аутентификацию пользователей в домене Microsoft Windows по сертификатам ГОСТ. Обычно подобные задачи решаются путем использования специализированного средства компании «КРИПТО-ПРО», а именно «КриптоПро Winlogon». Данный продукт существует на рынке достаточно давно и максимально проработан, но иногда могут возникать непредвиденные сложности при его внедрении, с которыми нашей компании и пришлось столкнуться. Для его функционирования необходимо соответствующим образом настроить рабочую станцию, домен и контроллеры домена. Одним из требований при настройке контроллера домена в данном случае является выпуск сертификата на ГОСТ.

В случае с нашим заказчиком возникла ситуация, при которой для доступа к контроллеру домена используется, кроме протокола LDAP, еще и LDAP через SSL (LDAPS) с использованием уже установленного на контроллере сертификата RSA.

Небольшое отступление: по умолчанию трафик LDAP не защищен, что предоставляет возможность осуществлять мониторинг трафика между LDAP–клиентом и сервером. Чтобы обеспечить передачу трафика LDAP в безопасном режиме, необходимо использовать технологию SSL/TLS, сокращенно такая технология называется LDAPS.

Комментарий из инструкции:

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

Итак, как же работает выбор сертификата контроллером домена?

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

Однако в Windows Server существует возможность легитимного использования нескольких сертификатов. Для этого используется отдельное хранилище Active Directory Domain Services (NTDS\Personal), в котором хранится сертификат для доступа по LDAPS.

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

Чтобы просмотреть хранилище сертификатов сервисов на контролере домена, необходимо запустить консоль управления (MMC) и добавить оснастку «Сертификаты». Далее с помощью диспетчера сертификатов следует выбрать тип управления сертификатами.

Затем необходимо выбрать учетную запись Active Directory Domain Services.

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

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

Источник

Аутентификация в продукте «Форсайт. Аналитическая платформа»

В продукте «Форсайт. Аналитическая платформа» доступно несколько методов аутентификации. Метод аутентификации выбирается в зависимости от требуемых мер безопасности.

Проверка учётных данных может производиться на сервере СУБД и/или в «Форсайт. Аналитическая платформа».

Настольное приложение

В настольном приложении доступны следующие базовые типы аутентификации:

Доступность базовых методов аутентификации зависит от используемой СУБД:

— тип аутентификации доступен;

— тип аутентификации недоступен.

Парольная аутентификация

Аутентификация производится с использованием логина и пароля. Доступна настройка парольной политики.

Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».

«Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.

Ролевая аутентификация

Ролевая аутентификация аналогична парольной, производится с использованием логина и пароля. Доступ к объектам определяется по присвоенным пользователю ролям на сервере СУБД, которые совпадают с группами в «Форсайт. Аналитическая платформа».

Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».

«Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.

СУБД возвращает список ролей пользователя. Список ролей сопоставляется со списком групп платформы. Пользователь получает права, соответствующие группам.

Доменная аутентификация

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

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

Пользователь вводит доменное имя и пароль в «Форсайт. Аналитическая платформа».

«Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.

СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.

Интегрированная доменная аутентификация

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

Метод аутентификации Kerberos:

При работе с СУБД Teradata интегрированная доменная аутентификация всегда осуществляется с использованием механизма аутентификации Kerberos. Для СУБД PostrgreSQL данный механизм может быть включён опционально в дополнительных параметрах соединения с репозиторием.

Для работы по протоколу Kerberos на клиентском компьютере необходимо установить MIT Kerberos (не входит в комплект поставки «Форсайт. Аналитическая платформа»).

Пользователь вводит доменное имя и пароль при входе в операционную систему.

«Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.

СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.

Двухфакторная аутентификация

Пользователь выполняет базовую аутентификацию в «Форсайт. Аналитическая платформа».

После запроса пользователь предоставляет «Форсайт. Аналитическая платформа» сертификат.

При совпадении сертификата «Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.

Встроенная аутентификация

При встроенной аутентификации доступ к данным СУБД происходит под встроенным администратором. Проверка прав пользователя осуществляется на уровне платформы. Учётные данные администратора хранятся в зашифрованном виде. Встроенная аутентификация настраивается через контроль доступа.

Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».

«Форсайт. Аналитическая платформа» проверяет разрешения пользователя и обращается к СУБД, используя учётные данные встроенного администратора.

Веб-приложение

Для веб-приложения доступны все варианты аутентификации настольного приложения, при этом роль настольного приложения выполняет BI-сервер.

Дополнительно для веб-приложения доступны следующие методы аутентификации:

OAuth

Аутентификация через протоколы OAuth 1.1 и 2.0 позволяет пользователю авторизоваться под учётной записью сервиса Twitter, Google и других. Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.

Пользователь вводит логин и пароль соответствующего сервиса.

Поставщик данных (сервис) передает BI-серверу подтверждение аутентификации пользователя.

BI-сервер обращается к СУБД, используя данные встроенного администратора.

Протокол SAML позволяет совершать обмен аутентификационными данными между поставщиком аутентификации и «Форсайт. Аналитическая платформа». Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.

Пользователь предоставляет логин и пароль поставщику аутентификации.

Поставщик аутентификации передает «Форсайт. Аналитическая платформа» результат проверки данных пользователя.

«Форсайт. Аналитическая платформа» обращается к СУБД, используя данные встроенного администратора.

Гостевой вход

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

Пользователь переходит по гостевой ссылке.

BI-сервер обращается к СУБД, используя заранее введённые логин и пароль от гостевой учётной записи.

Источник

Обзор способов и протоколов аутентификации в веб-приложениях

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

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

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

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:

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

Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.

Пример forms authentication.

Приложение может создать session token двумя способами:

Другие протоколы аутентификации по паролю

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

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

Распространенные уязвимости и ошибки реализации

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

Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.

Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.

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

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

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

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Пример SWT токена (после декодирования).

Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

Пример подписанного JWT токена (после декодирования 1 и 2 блоков).

Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

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

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

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

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

Заключение

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

Источник

• ← что такое роллеры фото
• что такое глонасс мониторинг →