Обзор
Справочный процесс цифровой регистрации и аутентификации Американским национальным институтом стандартов и технологий (NIST)
История
Существует три общепринятых фактора, которые используются для установления цифровой идентичности для электронной аутентификации, в том числе:
- Фактор знаний, который представляет собой то, что знает пользователь, например пароль, ответы на вопросы, идентификационные номера или PIN-код.
- Фактор владения, который есть у пользователя, например мобильный телефон, компьютер или токен.
- Биометрический фактор, которым является пользователь, например его или ее отпечатки пальцев, сканирование глаз или образец голоса.
Электронные учетные данные
Бумажные учетные данные — это документы, подтверждающие личность или другие атрибуты физического или юридического лица, называемые субъектом учетных данных. Некоторые общие бумажные документы включают паспорта, свидетельства о рождении, водительские права и удостоверения личности сотрудников. Сами учетные данные удостоверяются различными способами: традиционно, возможно, с помощью подписи или печати, специальной бумаги и чернил, высококачественной гравировки, а сегодня с помощью более сложных механизмов, таких как голограммы, которые делают учетные данные узнаваемыми и трудными для копирования или кузница. В некоторых случаях простого владения учетными данными достаточно, чтобы установить, что физический владелец учетных данных действительно является субъектом учетных данных. Чаще всего учетные данные содержат биометрическую информацию, такую как описание субъекта, изображение субъекта или собственноручную подпись субъекта, которая может использоваться для подтверждения того, что владелец учетных данных действительно является субъектом учетных данных. Когда эти бумажные учетные данные представлены лично, аутентификация биометрия Содержащиеся в этих учетных данных можно проверить, чтобы подтвердить, что физический держатель учетных данных является субъектом.
Верификаторы
Существует четыре типа схем аутентификации: локальная аутентификация, централизованная аутентификация, глобальная централизованная аутентификация, глобальная аутентификация и веб-приложение (портал).
При использовании локальной схемы аутентификации приложение сохраняет данные, относящиеся к учетным данным пользователя. Эта информация обычно не передается другим приложениям. Ответственность за поддержание и запоминание типов и количества учетных данных, связанных со службой, к которой им необходим доступ, возлагается на пользователя. Это схема высокого риска из-за возможности того, что область хранения паролей может быть скомпрометирована.
Использование центральной схемы аутентификации позволяет каждому пользователю использовать одни и те же учетные данные для доступа к различным службам. Каждое приложение индивидуально и должно иметь интерфейсы и иметь возможность взаимодействия с центральной системой для успешной аутентификации пользователя. Это позволяет пользователю получить доступ к важной информации и иметь доступ к закрытым ключам, которые позволят ему или ей подписывать документы электронным способом.
Использование третьей стороны через глобальную централизованную схему аутентификации позволяет пользователю получить прямой доступ к службам аутентификации. Затем это позволяет пользователю получить доступ к нужным им службам.
Совместная работа аутентификации и цифровой подписи
Биометрическая аутентификация существенно влияет на цифровые следы. Например, когда пользователь решает использовать свой отпечаток пальца для защиты своих данных на своем смартфоне, система запоминает ввод, чтобы его можно было использовать снова. Эта процедура и многие другие подобные приложения доказывают, что цифровые следы жизненно важны и существуют при биометрической аутентификации.
Связь
Еще одна характеристика биометрической аутентификации состоит в том, что она сочетает в себе различные компоненты, такие как токены безопасности, с компьютерными системами для защиты пользователя. Другой пример — соединение между устройствами, такими как камера, и компьютерными системами для сканирования сетчатки глаза пользователя и создания новых способов безопасности. Таким образом, биометрическая аутентификация может определяться связью, если она соединяет различные приложения или компоненты, и через них пользователи подключаются и могут работать под одной крышей, особенно в безопасной среде кибер-мира.
Перепрограммируемый и умный
Уровень уверенности 1: небольшая уверенность или отсутствие уверенности в достоверности заявленной личности. Уровень уверенности 2: некоторая уверенность в достоверности заявленной личности. Уровень уверенности 3: высокая уверенность в достоверности заявленной личности. Уровень уверенности 4: очень высокая уверенность в достоверности заявленной личности.
Определение уровней уверенности
OMB предлагает пятиэтапный процесс для определения соответствующего уровня гарантии для своих приложений:
- Проведите оценку риска, чтобы определить возможные негативные воздействия.
- Сравните с пятью уровнями уверенности и решите, какой из них подходит для этого случая.
- Выберите технологию в соответствии с техническим руководством NIST.
- Убедитесь, что выбранный процесс аутентификации удовлетворяет требованиям.
Требуемый уровень гарантии аутентификации оценивается с помощью следующих факторов:
- Неудобства, страдания или ущерб репутации или репутации;
- Финансовые убытки или ответственность агентства;
- Вред программам агентства или общественным интересам;
- Несанкционированный выпуск конфиденциальной информации;
Определение технических требований
- Жетоны используются для подтверждения личности. Пароли и симметричные криптографические ключи — это личная информация, которую проверяющий должен защищать. Асимметричные криптографические ключи имеют закрытый ключ (который знает только подписчик) и связанный с ним открытый ключ.
- Проверка личности, регистрация и доставка учетных данных, которые связывают личность с токеном. Этот процесс может включать операции на большом расстоянии.
- Учетные данные, токены и протоколы аутентификации также могут быть объединены вместе, чтобы определить, что заявитель на самом деле является заявленным подписчиком.
- Механизм утверждения, который включает либо цифровую подпись заявителя, либо приобретается непосредственно доверенной третьей стороной через безопасный протокол аутентификации.
Руководства и правила
Электронная аутентификация — это центральный элемент Правительство США усилия по расширению электронного правительства, или электронное правительство, как способ сделать правительство более эффективным, действенным и доступным. Служба электронной аутентификации позволяет пользователям получать доступ к государственным услугам в режиме онлайн, используя идентификаторы входа (идентификационные данные) с других веб-сайтов, которым доверяют как пользователь, так и правительство.
Европа
В Европа, eIDAS предоставляет руководящие принципы, которые следует использовать для электронной аутентификации в отношении электронных подписей и служб сертификатов для аутентификации веб-сайтов. После подтверждения выдающим государством-членом, другие государства-участники должны признать электронную подпись пользователя действительной для международных транзакций.
В рамках eIDAS электронная идентификация относится к материальной / нематериальной единице, которая содержит персональные идентификационные данные, которые будут использоваться для аутентификации для онлайн-сервиса. Аутентификация — это электронный процесс, который позволяет осуществлять электронную идентификацию физического или юридического лица. Служба доверия — это электронная служба, которая используется для создания, проверки и проверки электронных подписей, а также для создания, проверки и проверки сертификатов для аутентификации веб-сайтов.
Россия
Помимо государственных услуг, электронная аутентификация также широко используется в других технологиях и отраслях. Эти новые приложения сочетают в себе функции авторизации идентификационных данных в традиционной базе данных и новую технологию, чтобы обеспечить более безопасное и разнообразное использование электронной аутентификации. Некоторые примеры описаны ниже.
Мобильная аутентификация
С суверенная идентичность (SSI) индивидуальные держатели удостоверений полностью создают и контролируют свои учетные данные. В то время как верификаторы могут аутентифицировать предоставленные идентификаторы в децентрализованной сети.
Перспективы
- Веб-сайт электронной аутентификации правительства США
- Записка о директиве по электронной аутентификации от Randum M04-04
- DigiD — общая цифровая идентификация, внедренная налоговой администрацией Нидерландов и GBO.Overheid (Gemeenschappelijke Beheerorganisatie)
- Cartão do Cidadão — А португальский документ, позволяющий его владельцу надежно идентифицировать себя как в физическом, так и в цифровом мире
- Анимация электронной аутентификации — общие методы аутентификации (сценарий)
- Электронная аутентификация: руководство по выбору безопасных методов
- Насио Кто ты? Я действительно хочу знать: электронная аутентификация и ее последствия для конфиденциальности
- Руководство по электронной аутентификации (специальная публикация 800-63-2), август 2013 г.
- Национальная стратегия надежной идентификации в киберпространстве (NSTIC)
Обзор способов и протоколов аутентификации в веб-приложениях
Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.
- Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
- Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
- Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.
Например, при попытке попасть в закрытый клуб вас идентифицируют (спросят ваше имя и фамилию), аутентифицируют (попросят показать паспорт и сверят фотографию) и авторизуют (проверят, что фамилия находится в списке гостей), прежде чем пустят внутрь.
Однако в современных системах существуют и более сложные схемы аутентификации и авторизации, о которых я расскажу далее. Но начнем с простого и понятного.
Аутентификация по паролю
Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.
HTTP authentication
Весь процесс стандартизирован и хорошо поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:
- Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
- Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.
Forms authentication
Для этого протокола нет определенного стандарта, поэтому все его реализации специфичны для конкретных систем, а точнее, для модулей аутентификации фреймворков разработки.
Пример forms authentication.
Приложение может создать session token двумя способами:
- Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
- Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».
Другие протоколы аутентификации по паролю
- URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
- Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
Распространенные уязвимости и ошибки реализации
Аутентификации по паролю считается не очень надежным способом, так как пароль часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей. Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:
- Веб-приложение позволяет пользователям создавать простые пароли.
- Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
- Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
- Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
- Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
- Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
- Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
- Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
- Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
- Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.
Аутентификация по сертификатам
Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.
На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.
В веб-приложениях традиционно используют сертификаты стандарта X. 509. Аутентификация с помощью X. 509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.
Использование сертификата для аутентификации.
Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:
- Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
- Сертификат должен быть действительным на текущую дату (проверка срока действия).
- Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).
Пример X. 509 сертификата.
После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).
Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.
Аутентификация по одноразовым паролям
Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. востребовано для определенных видов веб-приложений.
Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т.
Существуют разные источники для создания одноразовых паролей. Наиболее популярные:
- Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
- Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
- Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.
Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.
В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.
Аутентификация по ключам доступа
В большинстве случаев, сервер генерирует ключи доступа по запросу пользователей, которые далее сохраняют эти ключи в клиентских приложениях. При создании ключа также возможно ограничить срок действия и уровень доступа, который получит клиентское приложение при аутентификации с помощью этого ключа.
Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.
Пример применения аутентификации по ключу.
Использование ключей позволяет избежать передачи пароля пользователя сторонним приложениям (в примере выше пользователь сохранил в веб-приложении не свой пароль, а ключ доступа). Ключи обладают значительно большей энтропией по сравнению с паролями, поэтому их практически невозможно подобрать. Кроме того, если ключ был раскрыт, это не приводит к компрометации основной учетной записи пользователя — достаточно лишь аннулировать этот ключ и создать новый.
Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с 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) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя. На общем уровне, весь процесс выглядит следующим образом:
- Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
- Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
- Клиент аутентифицируется в SP-приложении при помощи этого токена.
Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.
Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.
Пример аутентификации «пассивного» клиента посредством перенаправления запросов.
Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.
Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.
При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:
- Токен был выдан доверенным identity provider приложением (проверка поля issuer).
- Токен предназначается текущему SP-приложению (проверка поля audience).
- Срок действия токена еще не истек (проверка поля expiration date).
- Токен подлинный и не был изменен (проверка подписи).
В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.
Форматы токенов
Существует несколько распространенных форматов токенов для веб-приложений:
Стандарт SAML
Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1. 0 и 1. 1 были выпущены в 2002 – 2003 гг. , в то время как версия 2. 0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.
Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:
- Assertions — собственный формат SAML токенов в XML формате.
- Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
- Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.
Кроме того, стандарт определяет формат обмена метаинформацией между участниками, которая включает список поддерживаемых ролей, протоколов, атрибутов, ключи шифрования и т.
После того как браузер автоматически отправит эту форму на сайт 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 определяет:
- Формат и способы обмена метаданными о сервисах.
- Функцию единого выхода из всех систем (single sign-out).
- Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
- Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
- Поддержку пассивных клиентов (браузеров) посредством перенаправления.
Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.
Стандарты OAuth и OpenID Connect
В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).
Первая версия стандарта разрабатывалась в 2007 – 2010 гг. , а текущая версия 2. 0 опубликована в 2012 г. Версия 2. 0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1. Сейчас OAuth 2. 0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.
Чтобы лучше понять сам стандарт, рассмотрим пример веб-приложения, которое помогает пользователям планировать путешествия. Как часть функциональности оно умеет анализировать почту пользователей на наличие писем с подтверждениями бронирований и автоматически включать их в планируемый маршрут. Возникает вопрос, как это веб-приложение может безопасно получить доступ к почте пользователей, например, к Gmail?
Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:
- Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
- Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
- Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).
Взаимодействие компонентов в стандарте OAuth.
Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:
- Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
- Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
- Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).
Стандарт не определяет формат токена, который получает приложение: в сценариях, адресуемых стандартом, приложению нет необходимости анализировать токен, т. он лишь используется для получения доступа к ресурсам. Поэтому ни токен, ни грант сами по себе не могут быть использованы для аутентификации пользователя. Однако если приложению необходимо получить достоверную информацию о пользователе, существуют несколько способов это сделать:
Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1. 0 и 2. 0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.
Заключение
В этой статье мы рассмотрели различные методы аутентификации в веб-приложениях. Ниже — таблица, которая резюмирует описанные способы и протоколы:
Надеюсь, что информация оказалась полезна, и вы сможете применить ее при дизайне и разработке новых приложений. До новых встреч!
Способы аутентификации
HTTP Digest Authentication
Token Authentication
Следующее поколение способов аутентификации представляет Token Based Authentication, который обычно применяется при построении систем Single sign-on (SSO). При его использовании запрашиваемый сервис делегирует функцию проверки достоверности сведений о пользователе другому сервису. провайдер услуг доверяет выдачу необходимых для доступа токенов собственно токен-провайдеру (Identity provider). Это то, что мы видим, например, входя в приложения через аккаунты в социальных сетях. Вне IT самой простой аналогией этого процесса можно назвать использование общегражданского паспорта. Официальный документ как раз является выданным вам токеном — все государственные службы по умолчанию доверяет отделу полиции, который его вручил, и считает паспорт достаточным для вашей аутентификации на протяжении всего срока действии при сохранении его целостности.
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.