Что является наиболее серьезной проблемой парольной аутентификации пользователей на серверах
Почему не стоит надеяться на парольную защиту данных в 2021 году
Привычный для многих способ аутентификации с применением логина-пароля на сегодняшний день признан экспертами по информационной безопасности одним из самых ненадежных. Тому есть несколько причин: от человеческого фактора до технологий передачи. Что изменится в стандартах аутентификации в ближайшем будущем и как будем защищать себя от злоумышленников? Попробуем найти ответы на эти вопросы.
Что это такое
Говоря простыми словами, аутентификация – это процедура проверки подлинности чего-либо. В сфере современных информационных технологий это проверка подлинности пользователя, запрашивающего доступ к определенным ресурсам. Человек вводит буквенно-цифровые комбинации логина и пароля, а система безопасности автоматически сверяет их с хранящимися в базе данными.
Такая проверка призвана обеспечить сохранность файлов с личной информацией, документов, электронной почты и пр.
Представить без аутентификации сегодня невозможно, наверное, ни одно приложение. Особенно если учесть насколько серьезные данные могут там хранится.
Именно поэтому встал вопрос об уязвимости протокола простой аутентификации, основанного на передаче паролей на определенные серверы. При использовании незащищённых соединений пароли и логины становятся легкой добычей для злоумышленников, которые «считывают» их по пути к серверу или к клиенту.
Минусы парольной аутентификации
Мониторинг информационных систем показал, что уязвимость простой аутентификации кроется не только в особенностях технологии передачи данных, но и в человеческом факторе. Больше половины пользователей используют для паролей самые простые комбинации, причем часто одинаковые для доступа к разным системам.
Для «легкого запоминания» люди вводят расположенные в один ряд на клавиатуре буквы, не заморачиваясь сложным генерированием или выбирают пароли, которые легко угадать (даты рождения, имена и пр.). Такой подход – прямая угроза конфиденциальности данных, и в случае утечки пострадать могут сразу несколько ресурсов.
Парадокс, но администраторы информационных сетей очень часто поступают таким же образом.
Но главная опасность кроется в том, что можно передать пароль третьему лицу. Как известно, что знают двое – знают все, и если потеря персональных данных – личная трагедия пользователя, то утрата корпоративных данных – катастрофа для всей компании.
Самая надежная замена
Решить проблему поможет строгая двух или трехфакторная аутентификация.
Для проверки подлинности в этом случае используется:
Использование биометрических данных (отпечаток пальца, сканирование сетчатки глаза или распознавание голоса) также вызывает доверие, ввиду того, что эти данные практически невозможно подделать. Такая аутентификация избавляет от запоминания и ввода сложных паролей, попутно исключая возможность передачи ключей доступа третьим лицам, что намного безопаснее других способов защиты.
Обойти несколько ступеней проверки намного сложнее, чем один.
Тем более, что каждая ступень требует определенных инструментов и тактики.
В современном мире цифровые каналы связи становятся все более востребованными не только в корпоративной, но и в социальной среде. Надежная защита персональных данных – гарантия финансового и душевного спокойствия. Это значит, что применение более сложной многофакторной аутентификации – отнюдь не прихоть разработчиков, а насущная потребность каждого пользователя.
Парольная аутентификация пользователей компьютерных систем: основные недостатки и их причины, требования к паролям и к процедуре аутентификации
В настоящее время парольная аутентификация является наиболее распространенной, прежде всего, благодаря своему единственному достоинству – простоте использования.
Однако, парольная аутентификация имеет множество недостатков:
В отличие от случайно формируемых криптографических ключей (которые, например, может содержать уникальный предмет, используемый для аутентификации), пароли пользователя бывает возможно подобрать из-за достаточно небрежного отношения большинства пользователей к формированию пароля. Часто встречаются случаи выбора пользователями легко предугадываемых паролей, например:
· пароль эквивалентен идентификатору (имени) пользователя (или имени пользователя, записанному в обратном порядке, или легко формируется из имени пользователя и т.д.);
· достаточно часто пользователи применяют короткие пароли, которые взламываются методом «грубой силы», т.е. простым перебором всех возможных вариантов.
· Существуют и свободно доступны различные утилиты подбора паролей, в том числе, специализированные для конкретных широко распространенных программных средств. Например, на сайте www.lostpassword.com описана утилита подбора пароля для документа Microsoft Word 2000 (Word Password Recovery Key), предназначенная для восстановления доступа к документу, если его владелец забыл пароль. Несмотря на данное полезное назначение, ничто не мешает использовать эту и подобные ей утилиты для взлома чужих паролей
· Пароль может быть получен путем применения насилия к его владельцу.
· Пароль может быть подсмотрен или перехвачен при вводе.
Рекомендации по выбору хорошего пароля составлены для того, чтобы сделать пароль более стойким к разнообразным ухищрениям взломщиков.
· Минимальная длина пароля в пределах от 12 до 14 символов. Увеличение пароля всего на 2 символа дает в 500 раз больше вариантов, чем увеличение алфавита на 18 символов
· Генерирование случайных паролей, если это возможно
· Избегать пароли, основанные на повторении, словарных словах, буквенных или числовых последовательностях, имени пользователя, именах родственников или домашних животных, романтических отсылках (нынешних или прошлых), биографической информации.
· Включение в пароль цифр и иных символов, если это разрешено системой.
· Использовать как прописные, так и строчные буквы, когда это возможно.
· Избегать использовать один и тот же пароль для различных сайтов или целей.
SRP-6. Безопасная аутентификация по небезопасному каналу
Как аутентифицировать пользователя без передачи пароля на сервер? Возможно ли проверить, что пользователь ввёл правильный пароль, не передавая пароль на сервер. Да, такое возможно, благодаря доказательству нулевого разглашения.
Безопасная аутентификация складывается из 2 факторов – необходимо обеспечить надежный канал между клиентом и сервером и обеспечить правильное хранение аутентификационных данных на стороне сервера. И несмотря на то, что тема хранения паролей давно изъезжена вдоль и поперёк, мы постоянно натыкаемся на новости об очередной утечке пользовательских данных. Нередко отличаются даже крупные компании (утечка 100 миллионов аккаунтов пользователей ВК, утечка данных пользователей LinkedIn, Dropbox принудительно сбрасывает пароли после раскрытия учетных данных пользователей)
Что касается безопасного канала, то это решается с помощью HTTPS. Однако в ряде случаев возможна MITM-аттака. Например, пользователь может пренебречь предупреждением браузера, если кто-то пытается подменить сертификаты, или это может быть работодатель, который хочет следить за своими работниками. Эти две проблемы можно решить, используя протокол парольной аутентификации SRP (Secure Remote Password Protocol).
Алгоритм работы похож на алгоритм Диффи-Хеллмана и позволяет аутентифицировать пользователя на сервере при этом не передавая пароль в открытом виде, таким образом удостовериться в том, что пользователь знает свой пароль. На сервере данные хранятся в формате, который неэквивалентен открытому паролю пользователя, поэтому при утечке БД извлечь сам пароль не удастся. И т.к. пароль вообще не передается по каналу связи, то и защищенного канала не требуется. Реализуется доказательство с нулевым разглашением.
Рассмотрим основной принцип работы.
Регистрация нового пользователя
Для начала нужно определить необходимые в расчетах константы:
Не вдаваясь в математические подробности, значения этих чисел можно выбрать из RFC5054. appendix A. Для 1024-битной группы эти значения выглядят следующим образом:
Пользователь вводит login I и password p, далее на стороне клиента происходит генерация соли s, вычисление секретного ключа x и верификатора v, используя хэш-функцию H (например SHA-256):
Здесь и далее возведение в степень берется по модулю N. Значение x может вычисляться иначе, например x = H(s | H ( I | «:» | p) ). Включение логина в формулу расчета х позволит избежать проверки на сервере имеют ли 2 пользователя один и тот же пароль в случае взлома сервера, когда пользователь пытается войти.
Далее клиент передает на сервер значения I, v, s, и сервер сохраняет значения в БД. Вот тут решается одна проблема – если БД будет украдена, то не получится восстановить пароль из значений v и s.
Вход пользователя
Вход осуществляется в несколько этапов
Шаг 1
Пользователь вводит login I и password p. Клиент генерирует случайное целое число a, вычисляет публичное значение A:
Значение I и A передаются на сервер.
Сервер проверяет, что значение A != 0. По логину пользователя I из БД происходит выборка сохраненных при регистрации значений s (соль) и v (верификатор). Далее происходит генерация случайного целого числа b и вычисление публичного значения B:
Значения B и s передаются клиенту.
Шаг 2
Клиент проверяет, что B != 0 и вычисляет у себя значения параметра случайного кодирования u и сессионный ключ SC:
Аналогично на своей стороне сервер вычисляет свой сессионный ключ SS:
На этом этапе значения SC и SS равны, что можно доказать следующим образом:
Мы получили одинаковые значения сессионных ключей на обеих сторонах, не передавая значение верификатора. А тех данных, которые были переданы, недостаточно, чтобы определить чувствительные данные пользователя. В этом и заключается устойчивость протокола к прослушиванию и MITM-атаке.
Остается доказать друг другу, что их значения ключей совпадают. Для этого необходимо на стороне клиента вычислить значение M1 и передать его на сервер. Один из вариантов расчета:
Получив это значение, сервер вычисляет свое значение, т.к. имеет все для этого параметры, и сравнивает с полученным. Аутентификация выполнена.
Шаг 3 (опциональный)
Необходим, если требуется взаимная аутентификация. В этом случае сервер вычисляет значение M2 и отправляет клиенту:
Теперь уже клиент у себя рассчитывает значение M2 и сверяет с полученным. Если совпадают, то серверу можно доверять.
Чтобы минимизировать количество запросов к серверу, сгруппируем вычисления иначе, тогда процесс взаимодействия с сервером можно представить следующей сиквенс-диаграммой.
Реализация
Существуют реализации для разных языков программирования. Рассмотрим пример использования библиотеки Nimbus SRP для Java.
Определимся с основными параметрами, которые должны совпадать на клиенте и сервере. Для простоты не будем использовать слишком длинные значения. В данном случае выберем размер N 256 бит, алгоритм шифрование SHA-1:
Регистрация нового пользователя:
Вход пользователя
Клиент. Шаг 1. Ввод аутентификационных данных пользователя
Сервер. Шаг 1. Поиск пользователя в БД, вычисление B
Клиент. Шаг 2. Вычисление A и M1
Сервер. Шаг 2. Вычисление M2
Значение M1 вычисленное на клиентской стороне совпадает с таким же вычисленным на серверной, значения сессионных ключей также совпадают. Мы удостоверились, что пользователь знает пароль.
Вывод
SRP является отличным протоколом парольной аутентификации, устойчив к перебору по словарю, прослушиванию, подмены. Аутентификационные данные хранятся на сервере в виде, не позволяющем извлечь первоначальный пароль. Более того, алгоритм может использоваться для шифрования передаваемых данных.
Что является наиболее серьезной проблемой парольной аутентификации пользователей на серверах
Поставка и внедрение Check Point Next Generation Firewall.
Заказчик: «Государственный специализированный проектный институт» — проектирование объектов международного масштаба.
Год выполнения: 2020
Интеграция и настройка IP-телефонии Asterisk.
Заказчик: производственная компания «СПАРК» — производство и услуги волочения сварочной и нержавеющей проволоки.
Год выполнения: 2020
Проведение СП и СИ технических средств.
Заказчик: «Центр Сетевой Безопасности» — подбор решений и реализация проектов в области информационной безопасности.
Год выполнения: 2020
Отзывы клиентов
Ганин А.В., руководитель логистической и информационной службы Philipp Plein.
Русавский Р.Е., исполнительный директор по информационным технологиям АО «СОГАЗ».
Дополнительная информация
«Каждый из нас имеет право на свободу выбора. Правильно подобранный комплекс ИТ-решений — это инструмент, который позволяет нам самостоятельно выбирать образ жизни, включая дислокацию рабочего места, дресс-код и даже круг общения».
Елена Гуцало,
генеральный директор «Азон».
Вместе с образовательным порталом GeekBrains запустили факультатив про защиту персональных данных, в котором понятным языком структурировали информацию о том, что такое ПДн, где и в каком виде они могут находится, и как на практике обеспечить их защиту. Подробнее.
Обзор способов и протоколов аутентификации в веб-приложениях
Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (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, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.
Заключение
В этой статье мы рассмотрели различные методы аутентификации в веб-приложениях. Ниже — таблица, которая резюмирует описанные способы и протоколы: