Лекция
Привет, Вы узнаете о том , что такое аутентификация, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое аутентификация, авторизация, jwt, oauth2, oauth , настоятельно рекомендую прочитать все из категории информационная безопасность - Криптография и Криптоанализ. Стеганография. Защита Информации.
аутентификация (англ. authentication < греч. αὐθεντικός [authentikos] «реальный, подлинный» < αὐτός [autos] «сам; он самый») — процедура проверки подлинности, например:
В русском языке термин применяется, в основном, в области информационных технологий.
Учитывая степень доверия и политику безопасности систем, проводимая проверка подлинности может быть односторонней или взаимной. Обычно она проводится с помощью криптографических способов.
Аутентификацию не следует путать с авторизацией (процедурой предоставления субъекту определенных прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).
С древних времен перед людьми стояла довольно сложная задача — убедиться в достоверности важных сообщений. Придумывались речевые пароли, сложные печати. Появление методов аутентификации с применением механических устройств сильно упрощало задачу, например, обычный замок и ключ были придуманы очень давно. Пример системы аутентификации можно увидеть в старинной сказке «Приключения Али́-Бабы́ и сорока разбойников». В этой сказке говорится о сокровищах, спрятанных в пещере. Пещера была загорожена камнем. Отодвинуть его можно было только с помощью уникального речевого пароля: «Сим-Сим, откройся!».
В настоящее время в связи с обширным развитием сетевых технологий автоматическая аутентификация используется повсеместно.
Документы, определяющие стандарты аутентификации
Настоящий стандарт:
В настоящем стандарте изложены два вида аутентификации: простая, использующая пароль как проверку заявленной идентичности, и строгая, использующая удостоверения личности, созданные с использованием криптографических методов
Настоящий стандарт устанавливает Data Authentication Algorithm(DAA), который может быть использован для обнаружения несанкционированных изменений данных, как преднамеренных, так и случайных, стандарт основан на алгоритме, указанном в Data Encryption Standard(DES) Federal Information Processing Standards Publication(FIPS PUB) 46, и совместим как с Department of the Treasury’s Electronic Funds and Security Transfer Policy and the American National Standards Institute(ANSI) так и с Standard for Financial Institution Message Authentication.
Данный стандарт используется для контроля над целостностью передаваемой информации средствами криптографической аутентификации.
В любой системе аутентификации обычно можно выделить несколько элементов:
| Элемент аутентификации | Пещера 40 разбойников | Регистрация в системе | Банкомат |
|---|---|---|---|
| Субъект | Человек, знающий пароль | Авторизованный пользователь | Держатель банковской карты |
| Характеристика | Пароль "Сим-Сим, откройся!" | Тайный пароль | Банковская карта и персональный идентификатор |
| Хозяин системы | 40 разбойников | Предприятие, которому принадлежит система | Банк |
| Механизм аутентификации | Волшебное устройство, реагирующее на слова | Программное обеспечение, проверяющее пароль | Программное обеспечение, проверяющее карту и персональный идентификатор |
| Механизм управления доступом | Механизм, отодвигающий камень от входа в пещеру | Процесс регистрации, управления доступом | Разрешение на выполнение банковских действий |
Еще до появления компьютеров использовались различные отличительные черты субъекта, его характеристики. Сейчас использование той или иной характеристики в системе зависит от требуемой надежности, защищенности и стоимости внедрения. Выделяют 3 фактора аутентификации:
Федеральный закон от 06.04.2011 N 63-ФЗ «Об электронной подписи» (с изменениями) предусматривает следующие виды электронной подписи:
Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, в просторечии называемого «логином» (англ. login — регистрационное имя пользователя, учетка) и пароля — неких конфиденциальных сведений. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.
Простая аутентификация имеет следующий общий алгоритм:
Введенный субъектом пароль может передаваться в сети двумя способами:
С точки зрения наилучшей защищенности при хранении и передаче паролей следует использовать однонаправленные функции. Обычно для этих целей используются криптографически стойкие хеш-функции. В этом случае на сервере хранится только образ пароля. Получив пароль и проделав его хеш-преобразование, система сравнивает полученный результат с эталонным образом, хранящимся в ней. При их идентичности пароли совпадают. Для злоумышленника, получившего доступ к образу, вычислить сам пароль практически невозможно.
Использование многоразовых паролей имеет ряд существенных недостатков. Во-первых, сам эталонный пароль или его хешированный образ хранятся на сервере аутентификации. Зачастую хранение пароля производится без криптографических преобразований, в системных файлах. Получив доступ к ним, злоумышленник легко доберется до конфиденциальных сведений. Во-вторых, субъект вынужден запоминать (или записывать) свой многоразовый пароль. Злоумышленник может заполучить его, просто применив навыки социальной инженерии, без всяких технических средств. Кроме того, сильно снижается защищенность системы в случае, когда субъект сам выбирает себе пароль. Зачастую им оказывается какое-то слово или сочетание слов, присутствующие в словаре. В ГОСТ 28147-89 длина ключа составляет 256 бит (32 байта). При использовании генератора псевдослучайных чисел ключ обладает хорошими статистическими свойствами. Пароль же, который является, например, словом из словаря, можно свести к псевдослучайному числу длиной 16 бит, что короче ГОСТ-ового ключа в 16 раз. При достаточном количестве времени злоумышленник может взломать пароль простым перебором. Решением этой проблемы является использование случайных паролей или ограниченность по времени действия пароля субъекта, по истечении которого пароль необходимо поменять.
На компьютерах с ОС семейства UNIX базой является файл /etc/master.passwd (в дистрибутивах Linux обычно файл /etc/shadow, доступный для чтения только root), в котором пароли пользователей хранятся в виде хеш-функций от открытых паролей, кроме этого, в этом же файле хранится информация о правах пользователя. Изначально в Unix-системах пароль (в зашифрованном виде) хранился в файле /etc/passwd, доступном для чтения всем пользователям, что было небезопасно.
На компьютерах с операционной системой Windows NT/2000/XP/2003 (не входящих в домен Windows) такая база данных называется SAM (Security Account Manager — Диспетчер защиты учетных записей). База SAM хранит учетные записи пользователей, включающие в себя все данные, необходимые системе защиты для функционирования. Находится в каталоге %windir%\system32\config\.
В доменах Windows Server 2000/2003 такой базой является Active Directory.
Однако более надежным способом хранения аутентификационных данных признано использование особых аппаратных средств (компонентов).
При необходимости обеспечения работы сотрудников на разных компьютерах (с поддержкой системы безопасности) используют аппаратно-программные системы, позволяющие хранить аутентификационные данные и криптографические ключи на сервере организации. Пользователи свободно могут работать на любом компьютере (рабочей станции), имея доступ к своим аутентификационным данным и криптографическим ключам.
Заполучив однажды многоразовый пароль субъекта, злоумышленник имеет постоянный доступ к взломанным конфиденциальным сведениям. Эта проблема решается применением одноразовых паролей (OTP — One Time Password). Суть этого метода — пароль действителен только для одного входа в систему, при каждом следующем запросе доступа — требуется новый пароль. Реализован механизм аутентификации по одноразовым паролям может быть как аппаратно, так и программно.
Технологии использования одноразовых паролей можно разделить на:
В первом методе используется генератор псевдослучайных чисел с одинаковым значением для субъекта и для системы. Сгенерированный субъектом пароль может передаваться системе при последовательном использовании односторонней функции или при каждом новом запросе, основываясь на уникальной информации из предыдущего запроса.
Во втором методе используются временные метки. В качестве примера такой технологии можно привести SecurID. Она основана на использовании аппаратных ключей и синхронизации по времени. Аутентификация основана на генерации случайных чисел через определенные временные интервалы. Уникальный секретный ключ хранится только в базе системы и в аппаратном устройстве субъекта. Когда субъект запрашивает доступ в систему, ему предлагается ввести PIN-код, а также случайно генерируемое число, отображаемое в этот момент на аппаратном устройстве. Система сопоставляет введенный PIN-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введенного субъектом.
Третий метод основан на единой базе паролей для субъекта и системы и высокоточной синхронизации между ними. При этом каждый пароль из набора может быть использован только один раз. Благодаря этому, даже если злоумышленник перехватит используемый субъектом пароль, то он уже будет недействителен.
По сравнению с использованием многоразовых паролей одноразовые пароли предоставляют более высокую степень защиты.
Актуальность обеспечения безопасности мобильных средств коммуникации, например, ip-phone, стимулирует новые разработки в этой области. Среди них можно назвать аутентификацию с помощью SMS-сообщений.
Процедура такой аутентификации включает в себя следующие шаги:
Привлекательность данного метода заключается в том, что ключ получается не по тому каналу, по которому производится аутентификация (out-of-band), что практически исключает атаку типа «человек посередине». Дополнительный уровень безопасности может дать требование ввода PIN-кода мобильного средства.
Данный метод получил широкое распространение в банковских операциях через интернет.
Методы аутентификации, основанные на измерении биометрических параметров человека, обеспечивают почти 100 % идентификацию, решая проблемы утраты паролей и личных идентификаторов.
Примерами внедрения указанных методов являются системы идентификации пользователя по рисунку радужной оболочки глаза, отпечаткам ладони, формам ушей, инфракрасной картине капиллярных сосудов, по почерку, по запаху, по тембру голоса и даже по ДНК.
Новым направлением является использование биометрических характеристик в интеллектуальных расчетных карточках, жетонах-пропусках и элементах сотовой связи. Например, при расчете в магазине предъявитель карточки кладет палец на сканер в подтверждение, что карточка действительно его.
В то же время биометрическая аутентификация имеет ряд недостатков:
Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местонахождению. Данный защитный механизм основан на использовании системы космической навигации, типа GPS (Global Positioning System).
Пользователь, имеющий аппаратуру GPS, многократно посылает координаты заданных спутников, находящихся в зоне прямой видимости. Подсистема аутентификации, зная орбиты спутников, может с точностью до метра определить месторасположение пользователя. Высокая надежность аутентификации определяется тем, что орбиты спутников подвержены колебаниям, предсказать которые достаточно трудно. Кроме того, координаты постоянно меняются, что сводит на нет возможность их перехвата.
Сложность взлома системы состоит в том, что аппаратура передает оцифрованный сигнал спутника, не производя никаких вычислений. Все вычисления о местоположении производят на сервере аутентификации.
Аппаратура GPS проста и надежна в использовании и сравнительно недорога. Это позволяет ее использовать в случаях, когда авторизованный удаленный пользователь должен находиться в нужном месте.
Данный механизм основан на использовании информации о местоположении серверов, точек доступа беспроводной связи, через которые осуществляется подключение к сети интернет.
Относительная простота взлома состоит в том, что информацию о местоположении можно изменить, используя так называемые прокси-серверы или системы анонимного доступа.
В последнее время все чаще применяется так называемая расширенная, или многофакторная, аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищенность системы.
В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).
Также, к примеру, в некоторых современных ноутбуках присутствует сканер отпечатка пальца. Таким образом, при входе в систему субъект должен пройти эту процедуру (биометрика), а потом ввести пароль.
Выбирая для системы тот или иной фактор или способ аутентификации, необходимо, прежде всего, отталкиваться от требуемой степени защищенности, стоимости построения системы, обеспечения мобильности субъекта.
Можно привести сравнительную таблицу:
| Уровень риска | Требования к системе | Технология аутентификации | Примеры применения |
|---|---|---|---|
| Низкий | Требуется осуществить аутентификацию для доступа к системе, причем кража, взлом, разглашение конфиденциальных сведений не будут иметь значительных последствий | Рекомендуется минимальное требование - использование многоразовых паролей | Регистрация на портале в сети Интернет |
| Средний | Требуется осуществить аутентификацию для доступа к системе, причем кража, взлом, разглашение конфиденциальных сведений причинят небольшой ущерб | Рекомендуется минимальное требование - использование одноразовых паролей | Произведение субъектом банковских операций |
| Высокий | Требуется осуществить аутентификацию для доступа к системе, причем кража, взлом, разглашение конфиденциальных сведений причинят значительный ущерб | Рекомендуется минимальное требование - использование многофакторной аутентификации | Проведение крупных межбанковских операций руководящим аппаратом |
Процедура аутентификации используется при обмене информацией между компьютерами, при этом используются весьма сложные криптографические протоколы, обеспечивающие защиту линии связи от прослушивания или подмены одного из участников взаимодействия. А поскольку, как правило, аутентификация необходима обоим объектам, устанавливающим сетевое взаимодействие, то аутентификация может быть и взаимной.
Таким образом, можно выделить несколько семейств аутентификации:
Аутентификация пользователя на PC:
Аутентификация в сети:
В операционных системах семейства Windows NT 4 используется протокол NTLM (NT LAN Manager — Диспетчер локальной сети NT). А в доменах Windows 2000/2003 применяется гораздо более совершенный протокол Kerberos.
Аутентификация требуется при доступе к таким сервисам как:
Положительным результатом аутентификации (кроме установления доверительных отношений и выработки сессионного ключа) является авторизация пользователя, то есть предоставление ему прав доступа к ресурсам, определенным для выполнения его задач.
Файл cookie - это небольшой фрагмент данных, созданный сервером и отправленный в ваш браузер при посещении веб-сайта. Браузерам часто необходимо сохранить и отправить его обратно на сервер, чтобы сообщить, что запрос исходит от того же браузера, чтобы пользователь оставался аутентифицированным. Мы читаем файлы cookie браузера как пары «ключ-значение».
Аутентификация на основе файлов cookie использует файлы cookie HTTP для проверки подлинности клиентских запросов и сохранения информации о сеансе на сервере по протоколу HTTP без сохранения состояния .
Вот логическая последовательность процесса аутентификации на основе файлов cookie:
Клиент отправляет запрос на вход с учетными данными на внутренний сервер.
Затем сервер проверяет учетные данные. В случае успешного входа в систему веб-сервер создаст сеанс в базе данных и включит Set-Cookieзаголовок в ответ, содержащий уникальный идентификатор в объекте cookie.
Браузер сохраняет файл cookie локально. Пока пользователь остается в системе, клиент должен отправлять cookie во всех последующих запросах на сервер. Затем сервер сравнивает идентификатор сеанса, хранящийся в файле cookie, с идентификатором в базе данных для проверки действительности.
Во время операции выхода из системы сервер истечет срок действия cookie, удалив его из базы данных.
При аутентификации на основе токенов мы сохраняем состояние пользователя на клиенте. Веб-токен JSON (JWT) - это открытый стандарт (RFC 7519), который определяет способ безопасной передачи информации между клиентом и сервером в виде объекта JSON. В статье я буду использовать токены и термины JWT как синонимы.
Jwt.io веб - сайт может быть использован для анализа лексем информации JWT. Вы можете использовать jwt.io для экспериментов с веб- токенами JSON путем их декодирования и кодирования.
Анатомия токена JWT состоит из трех частей, разделенных точками (.). Эти три части включают заголовок JWT, полезную нагрузку JWT и его подпись соответственно ( header.payload.signature).
Пример токена JWT:
Заголовок JWT - это объект JSON в кодировке Base64 URL. Он содержит информацию, описывающую тип токена и используемый алгоритм подписи, например HMAC, SHA256 или RSA.
Пример:
Полезная нагрузка JWT содержит утверждения, которые являются частью информации, заявленной о предмете. В претензиях будут содержаться утверждения о пользователе и любые другие дополнительные данные. Утверждения в JWT кодируются как объект JSON, который используется в качестве полезной нагрузки веб-подписи JSON. Претензии могут быть зарегистрированными, публичными или частными.
Пример:
Создание подписи JWT включает в себя получение закодированного заголовка, закодированной полезной нагрузки, секретного ключа и применение указанного алгоритма.
Пример:
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Это создаст токен JWT с использованием HMAC SHA256алгоритма. Это подпись для проверки того, что токен не изменяется, когда секретный ключ применяется к бэкэнду.
Аутентификация с помощью токенов - это механизм без сохранения состояния, поскольку никакая информация о пользователе никогда не сохраняется в памяти сервера или базах данных. Следовательно, нет проблем с доменами, обслуживающими ваши API и последующие сервисы .
Процесс аутентификации с помощью токенов в веб-приложении:
Пользователь отправляет учетные данные для входа на внутренний сервер.
По запросу сервер проверяет учетные данные перед созданием зашифрованного JWT с секретным ключом и отправляет его обратно клиенту.
На стороне клиента браузер хранит токен локально, используя локальное хранилище, хранилище сеансов или хранилище файлов cookie.
В будущих запросах JWT добавляется к заголовку авторизации с префиксом носителя, и сервер проверяет свою подпись, декодируя токен, прежде чем приступить к отправке ответа. Содержание заголовка будет выглядеть следующим образом : Authorization: Bearer .
При выходе из системы токен на стороне клиента уничтожается без взаимодействия с сервером.
Обратите внимание: включайте только ту информацию, которая необходима в JWT, и удаляйте любую конфиденциальную информацию, чтобы предотвратить атаки безопасности межсайтового скриптинга (XSS).
Подход к аутентификации токена не имеет состояния. Веб-серверу не нужно будет вести учет токенов, поскольку каждый из них является самодостаточным, включая данные, необходимые для проверки его действительности и передачи информации о пользователе через утверждения. Серверу нужно только подписать токены при успешном входе в систему и убедиться, что входящие токены в запросах действительны.
Подход к аутентификации на основе токенов с включенным CORS упрощает предоставление API-интерфейсов различным службам и доменам. Это означает, что API может обслуживать как веб-платформы, так и мобильные платформы, такие как iOS и Android, и его намного проще реализовать, что делает их готовыми для мобильных устройств.
Данные хранятся в JWT, что означает, что они могут содержать данные любого типа, что дает гибкость в отношении того, какая информация должна быть включена в токен.
Это улучшает общую производительность системы. Например, если у вас была такая конечная точка API, /api/booksкоторая извлекает все книги в базе данных, где только пользователи с ролью администратора имеют доступ к этим данным. В подходе, основанном на файлах cookie, после вызова сервера у вас может быть один вызов базы данных, проверяющий, что идентификатор сеанса в файле cookie действителен, другой - для получения данных о пользователе и проверки роли администратора, и, наконец, третий вызов для получения данных. При подходе JWT роль может храниться в самом JWT, где ее декодирование может занять меньше времени, чем поиск в базе данных. Итак, после того, как вызов сделан на сервер и JWT проверен, можно запустить единственный вызов базы данных для извлечения книг.
В распределенных системах их легче поддерживать и горизонтально масштабировать.
Хранение большого количества данных в токене делает его огромным, что замедляет запросы.
Токены нельзя использовать для аутентификации пользователя в фоновом режиме на сервере, поскольку в базе данных нет сеанса.
Хранение токенов на стороне клиента проблематично. Когда токен хранится в cookie, они менее эффективны при большом размере JWT. Вы можете сохранить токен в хранилище сеанса, но он очищается при закрытии браузера. В локальном хранилище JWT будет привязан к определенному домену.
Токен на стороне клиента может быть захвачен злоумышленником, что сделает его уязвимым для атак межсайтового скриптинга (XSS). Это происходит, когда внешний объект может выполнять код в вашем домене, внедряя вредоносный JavaScript на страницу для чтения и компрометации содержимого хранилища браузера.
Оба подхода - не панацея при защите вашей системы.
Таким образом, будет разумно выбирать аутентификацию по токену, когда:
Когда есть необходимость использовать разные домены в системе. Например, если вы находитесь в домене section.com, который хочет отправить аутентифицированный запрос в домен github.com, использование токенов становится удобным. Это полезно при построении распределенных систем, особенно микросервисов в облаке, где серверы находятся в разных доменах, но между ними требуется аутентификация.
Токены будут полезны, когда API используется на разных платформах, таких как Интернет, Интернет вещей и мобильные устройства.
Выбирайте аутентификацию файлов cookie, когда:
Когда профиль пользователя требует персонализации. Когда нам нужны пользовательские настройки, такие как темы, мы будем использовать сеанс cookie в базе данных. Файлы cookie также используются для создания целевой рекламы для разных пользователей.
Если сайту необходимо отслеживать пользователя, анализируя и записывая поведение пользователя во время навигации по сайту. Примером на торговых сайтах является список недавно просмотренных пользователем товаров.
Сеансы, касающиеся входов в систему, тележек для покупок и результатов игр, могут нуждаться в отслеживании и сохранении в базе данных. Без файлов cookie вам нужно будет входить в систему каждый раз, когда вы покидаете сайт или восстанавливаете корзину покупок, если страница закрыта.
JWT (JSON Web Tokens) - это просто формат токена. Токены JWT представляют собой структуры данных в кодировке JSON, содержащие информацию об эмитенте, субъекте (утверждениях), сроке действия и т.д. Он подписан для защиты от несанкционированного доступа и подлинности, и он может быть зашифрован для защиты информации токена с использованием симметричного или асимметричного подхода. JWT проще, чем SAML 1.1 / 2.0, поддерживается всеми устройствами, и он более мощный, чем SWT (простой веб-токен). JWT - это открытый стандарт, который определяет компактный и автономный способ безопасной передачи информации между сторонами. Это протокол аутентификации, в котором мы позволяем передавать закодированные утверждения (токены) между двумя сторонами (клиентом и сервером), а токен выдается после идентификации клиента. При каждом последующем запросе мы отправляем токен. JWT ( Learn JSON Web Tokens ) - это формат токена, он определяет компактный и автономный механизм для передачи данных между сторонами таким образом, чтобы его можно было проверить и доверять, поскольку он имеет цифровую подпись. Кроме того, правила кодирования JWT также делают эти токены очень простыми в использовании в контексте HTTP. Таким образом Jwt - это строгий набор инструкций для выпуска и проверки подписанных токенов доступа. Токены содержат утверждения, которые используются приложением для ограничения доступа пользователя. Будучи самодостаточными (фактический токен содержит информацию о заданном предмете), они также являются хорошим выбором для реализации механизмов аутентификации без сохранения состояния ( никаких сессий ). При переходе по этому маршруту единственное, что сторона должна представить, чтобы получить доступ к защищенному ресурсу, - это сам токен, данный токен можно назвать токеном-носителем.
Механизм аутентификации на основе JWT токена
Механизм аутентификации на основе токена не имеет состояния, аналогично протоколу HTTP. Нет необходимости резервировать информацию для аутентификации пользователя или информацию о сеансе на сервере. Это означает, что приложению, основанному на механизме аутентификации токена, не нужно учитывать, на каком сервере входит пользователь, что обеспечивает удобство расширения приложения.
Процесс выглядит следующим образом:
Этот токен необходимо передавать на сервер каждый раз, когда он запрашивается. Его нужно сохранить в заголовке запроса. Кроме того, сервер должен поддерживать его CORS (cross source resource sharing)стратегию. Как правило, мы можем сделать это на стороне сервера Access-Control-Allow-Origin: *.
OAuth — открытый протокол (схема) авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищенным ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. OAuth является протоколом авторизации, который позволяет предоставить права на использование какого-то ресурса (например, API какого-либо сервиса). Наличие прав определяется токеном (уникальным идентификатором), который может быть одним и тем же для разных пользователей, или же у одного пользователя в разное время могут быть разные токены. Предоставление прав происходит в обмен на предоставление токена. В общем случае нельзя определить, кому принадлежит токен и кто в настоящий момент пользуется правами.
OAuth2 - OAuth - это открытый стандарт делегирования доступа, который обычно используется пользователями Интернета как способ предоставить веб-сайтам или приложениям доступ к своей информации на других веб-сайтах, но без предоставления им паролей . Этот механизм используется такими компаниями, как Google, Facebook, Microsoft и Twitter, чтобы пользователи могли делиться информацией о своих учетных записях со сторонними приложениями или веб-сайтами.OAuth2 - это структура авторизации, где у него есть общие процедуры и настройки, определенные структурой. JWT можно использовать как механизм внутри OAuth2. OAuth2 решает проблему, связанную с тем, что пользователь хочет получить доступ к данным с помощью клиентского программного обеспечения, такого как веб-приложения на основе просмотра, собственные мобильные приложения или настольные приложения. OAuth2 предназначен только для авторизации, клиентское программное обеспечение может быть авторизовано для доступа к ресурсам от имени конечного пользователя с помощью токена доступа. OAuth 2.0 определяет протокол, то есть указывает, как передаются токены, JWT определяет формат токена. OAuth 2.0 и «аутентификация JWT» имеют схожий вид, когда дело доходит до (2) стадии, когда Клиент представляет токен серверу ресурсов: токен передается в заголовке. Но «JWT-аутентификация» не является стандартом и не определяет, как Клиент получает токен в первую очередь (1-й этап). Вот откуда возникает воспринимаемая сложность OAuth: он также определяет различные способы, которыми Клиент может получить токен доступа от того, что называется Сервером авторизации. Ключевой момент здесь access delegation. Зачем кому-либо создавать OAUTH, когда есть аутентификация на основе id / pwd, поддерживаемая многофакторной аутентификацией, например OTP, и, кроме того, может быть защищена JWT, которые используются для защиты доступа к путям (например, области в OAUTH) и устанавливают истечение срока действия доступ. Нет смысла использовать OAUTH, если потребители получают доступ к своим ресурсам (вашим конечным точкам) только через свои доверенные веб-сайты (или приложения), которые снова размещены вами на ваших конечных точках. Вы можете пройти аутентификацию OAUTH только в том случае, если вы являетесь OAUTH providerвладельцем ресурсов (пользователей), которые хотят получить доступ к своим (вашим) ресурсам (конечным точкам) через сторонний клиент (внешнее приложение). И он создан именно для той же цели, хотя вообще можно злоупотреблять им. Еще одно важное замечание: вы свободно используете слово authenticationдля JWT и OAUTH, но не обеспечиваете механизм аутентификации. Да, один из них - механизм токена, а другой - протокол, но после аутентификации они используются только для авторизации (управления доступом). Вы должны поддерживать OAUTH либо с аутентификацией типа OPENID, либо с вашими собственными учетными данными клиента.
Таким образом, реальная разница в том, что JWT - это просто формат токена, а OAuth 2.0 - это протокол (который может использовать JWT в качестве формата токена).Если вы хотите полностью выйти из системы, вы должны использовать OAuth2. Аутентификация с помощью токена JWT фактически не позволяет выйти из системы. Потому что у вас нет сервера аутентификации, который отслеживает токены. Если вы хотите предоставить API сторонним клиентам, вы также должны использовать OAuth2. OAuth2 очень гибкий. Реализация JWT очень проста и не занимает много времени. Если вашему приложению нужна такая гибкость, вам следует использовать OAuth2. Но если вам не нужен этот сценарий использования, внедрение OAuth2 - пустая трата времени.
Для OAuth есть разные типы токенов:
И есть разные схемы взаомодействия
псевдо-аутентификации с использованием OAuth OAuth - это протокол авторизации , а не протокол аутентификации . Использование OAuth как метода аутентификации может называться псевдо-аутентификацией.
Поток неявного доступа ( Implicit Grant Flow)
Является самым коротким потоком протокола: пользователь сначала перенаправляется клиентом на сервер, чтобы разрешить доступ к ресурсам, а после того, как доступ будет получен, перенаправляется сервером обратно к клиенту.
Отличие данного потока от потока неявного доступа заключается в дополнительном шаге аутентификации клиента.
Отличия этого потока от приведенного примера в следующем: на шаге 2 сервер помимо токена доступа, который имеет ограниченное время жизни, выдает токен обновления; на шаге 8 сервер проверяет, является ли токен доступа валидным (в смысле истечения времени жизни), и в зависимости от этого либо предоставляет доступ к ресурсам, либо требует обновления токена доступа (который предоставляется при предъявлении токена обновления).
В этом потоке владелец ресурсов предоставляет клиенту логин и пароль, он передает их серверу и получает токен для доступа к ресурсам. Несмотря на то, что такой режим работы несколько противоречит концепции создания протокола, он описан в спецификации.
В данном режиме работы протокола предоставление сервером токена доступа происходит после передачи клиентом его пользователя и пароля, который был предварительно установлен сервером авторизации (в спецификации не оговорено, каким именно образом). Фактически, клиент сразу проходит как авторизацию, так и аутентификацию.
Вот некоторые основные плюсы и минусы OAuth 2.0.
OpenID Connect - OpenID Connect строится поверх OAuth2 и добавляет аутентификацию. OpenID Connect добавляет некоторые ограничения к OAuth2, такие как конечная точка UserInfo, идентификатор идентификатора, обнаружение и динамическая регистрация поставщиков OpenID Connect и управление сеансом. JWT - это обязательный формат для токена. OpenID Connect, который находится поверх OAUTH2, дает вам аутентификацию и авторизацию. Он подробно описывает, как несколько разных ролей, пользователи в вашей системе, серверные приложения, такие как API, и клиенты, такие как веб-сайты или собственные мобильные приложения, могут аутентифицироваться с каждым другим/
OpenID является средством аутентификации: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдает. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.
CSRF (англ. cross-site request forgery — «межсайтовая подделка запроса», также известна как XSRF) — вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от ее лица тайно отправляется запрос на другой сервер (например, на сервер платежной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счет злоумышленника). Для осуществления данной атаки жертва должна быть аутентифицирована на том сервере, на который отправляется запрос, и этот запрос не должен требовать какого-либо подтверждения со стороны пользователя, которое не может быть проигнорировано или подделано атакующим скриптом. Основное применение CSRF — вынуждение выполнения каких-либо действий на уязвимом сайте от лица жертвы (изменение пароля, секретного вопроса для восстановления пароля, почты, добавление администратора и т. д.). Также с помощью CSRF возможна эксплуатация отраженных XSS, обнаруженных на другом сервере.
Защита CSRF - вам не нужно внедрять защиту CSRF, если вы не храните токен в файле cookie браузера. Токен XSRF всегда отправляется клиенту в каждом заголовке ответа. Не имеет значения, отправлен ли токен CSRF в токене JWT или нет, потому что токен CSRF защищен самим собой. Поэтому отправка токена CSRF в JWT не требуется. В Oaut2 Клиент ДОЛЖЕН реализовать защиту CSRF для своего URI перенаправления. Обычно это достигается путем включения в любой запрос, отправляемый конечной точке URI перенаправления, значение, которое привязывает запрос к состоянию аутентификации пользовательского агента (например, хэш файла cookie сеанса, используемого для аутентификации агента пользователя). Клиенту СЛЕДУЕТ использовать параметр запроса «состояние» для доставки этого значения серверу авторизации при выполнении запроса авторизации.Атака CSRF на конечную точку авторизации сервера авторизации может привести к тому, что злоумышленник получит авторизацию конечного пользователя для злонамеренного клиента, не вовлекая и не предупреждая конечного пользователя. Сервер авторизации ДОЛЖЕН реализовать защиту CSRF для своей конечной точки авторизации и гарантировать, что злонамеренный клиент не сможет получить авторизацию без ведома и явного согласия владельца ресурса.
Аутентификация повышает безопасность системы, предоставляя аутентифицированным пользователям доступ к защищенным ресурсам.
В этой статье мы сравнили аутентификацию на основе файлов cookie и аутентификацию на основе токенов. Мы выделили преимущества и недостатки, возникающие при выборе любого из этих подходов.Если у вас есть очень простые сценарии, такие как одно клиентское приложение, один API, тогда переход на OAuth 2.0 может не окупиться, с другой стороны, множество разных клиентов (браузерные, собственные мобильные, серверные и т. д.), то соблюдение правил OAuth 2.0 может сделать его более управляемым, чем попытки развернуть собственную систему.
В информационных технологиях посредством авторизации устанавливаются права доступа к информационным ресурсам и системам обработки данных. Для этого применяются различные виды авторизации, которые можно поделить на три класса:
В случае дискреционного (избирательного) управления (DAC), доступ к объектам, данным или функциям, предоставляется явно указанным субъектам, пользователям или группам пользователей. Например, пользователю user_1 разрешено читать файл file_1, но запрещено в него писать. Каждый объект имеет привязанного к нему субъекта — владельца, который и устанавливает права доступа к объекту. Также система имеет одного выделенного субъекта — суперпользователя, имеющего право устанавливать права доступа для всех субъектов. А любой субъект может передавать имеющиеся у него права другим субъектам. Такой доступ используется в современных операционных системах, где для авторизации наиболее распространено использование полномочий и списков контроля доступа (ACL).
Мандатный доступ (MAC) заключается в разделении информации по степени секретности, а пользователей по уровням допуска к этой информации. Главным преимуществом мандатного доступа заключается в ограничении прав владельца объекта. Права субъектов на создаваемые ими объекты будут зависеть от их уровня допуска, соответственно они не смогут случайно или преднамеренно делегировать их неавторизированным пользователям. Согласно требованиям ФСТЭК мандатное управление доступом является ключевым отличием систем защиты Государственной Тайны РФ старших классов 1В и 1Б от младших классов защитных систем, основанных на дискреционной модели. Поддержка мандатного управления доступом присутствует в некоторых операционных системах, таких как Ubuntu, SUSE Linux, FreeBSD. Также используется в системах управления базами данных. Иногда применяется вместе с дискреционным контролем доступа.
Развитием политики избирательного доступа является управление доступом на основе ролей (RBAC), где доступ к объектам системы формируется с учетом специфики их применения на основе роли субъектов в каждый момент времени. Роли позволяют определить понятные для пользователей правила разграничения доступа. Роль сочетает свойства избирательного управления доступом, ставя в соответствие субъектам объекты, и мандатного, при изменении ролей изменится и доступ к группе файлов, но этот тип доступа более гибкий, по сравнению с предыдущими, и может их моделировать. Сейчас RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R/3, Lotus Notes и множество других.
Наиболее известные «простые» методы авторизации/регистрации на веб-ресурсах, которые не требуют специальных устройств - это смарт карты, устройства для сканирования отпечатков пальцев, сетчатки глаз и т.д.
Способы защиты аутентификации и ролевая авторизация.
Алгоритмы идентификации и аутентификации при двухфакторной авторизации в информационных системах.
Основные механизмы обеспечения аутентификации и защищенного туннельного соединения на базе VPN клиента TINC.
Термин «авторизация» применительно к банковской сфере означает процедуру получения разрешения от банка-эмитента или иного юридического лица (к примеру, процессинговой компании), который действует от его имени, на проведение операции по карте. Запрос на авторизацию содержит в себе информацию о банковской карте, сумме покупки или выдачи по банковской карте. Положительный ответ на авторизацию свидетельствует о том, что данная банковская карта действительна и остаток на ней позволяет совершить необходимую операцию. Отрицательный ответ на авторизацию, соответственно, может быть следствием наличия неполадок в платежной системе или недостатка средств на счете карты. После совершения операции электронное устройство выдает чек .
В финансовой сфере авторизация проводится при использовании банковских, платежных, кредитных и иных карт. Авторизация производится в случае превышения неавторизованного лимита — суммы, установленной банком, не требующей авторизации. Для магнитной банковской карты необходима авторизация, так как она не хранит информацию о счете. Авторизация может быть автоматической (с использованием POS-терминала), значительно реже голосовой.
Для предотвращения мошеннических действий в процессе авторизации клиентов банкоматов и платежных терминалов был предложен алгоритм создания программного обеспечения онлайн-мониторинга авторизации клиентов на базе искусственного интеллекта. Для этого использовались общенаучные методы (наблюдение, сравнение); экономико-статистические методы обработки данных (группировка, сравнение, анализ воздействия на бизнес (BIA)), анализ причин и следствий, техническое обслуживание, направленное на обеспечение надежности.
Использование самообучающихся машинных систем в процессе авторизации пользователей банкоматов.[10]
В бизнесе — выдача лицензии (например: уполномоченный или авторизированный автомобильный дилер) .
Авторизация перевода — перевод, просмотренный и одобренный автором или сделанный с согласия автора оригинала . Такой вид перевода публицистического или художественного произведения, при котором переводчик становится автором переведенного текста. Отличается значительными изменениями оригинала, далеко выходящими за рамки обычной при переводе адаптации и стилистической переработки. Переводчик может применять свои собственные творческие приемы, изменять состав героев и даже перекраивать сюжет произведения .
Авторизация в общедоступных сетях Wi-Fi посредством СМС.
Довольно важной задачей при разработке веб-сайтов и веб-приложений есть ограничение доступа к некоторым разделам сайта, например к панели администратора. В теории это достаточно сложный процесс, с трема составляющими - аутентификация, идентификация и авторизация (англ. authentication, identification, authorization).
Система аутентификации/авторизации в представлении разработчиков Symfony framework
Сразу после введения учетных данных (это может быть пара логин/пароль, одноразовый пароль, access token, md5-шифр, сертификат и многое другое) начинается процедура аутентификации (authentication). Она заключается в проверке подлинности. Например, сопоставить имя/пароль пользователя с учетной записью в базе данных, проверка контрольной суммы файла и т.д.
В общем случае, для процедуры аутентификации нужно либо что-то знать (например, пароль), либо иметь устройство аутентификации (например, ваш смартфон во многих современных электронных банковских системах), либо какие-то уникальных биометрические данные - отпечатки пальцев, рельеф лица, голос, радужная оболочка глаза и т.д.
Если процедура аутентификации прошла успешно, следующим шагам является идентификация. Задача идентификации - получить идентификатор пользователя в системе. Это может быть его id, уникальный логин, почта и т.д. Это что-то, с чем манипулирует веб-сайт.
И, наконец-то, после всего этого происходит авторизация. Суть авторизации в наделению пользователя некоторыми правами. Например, права администратора, пользователя, анонима (неавторизированного пользователя).
Зачастую, в php скриптах нет четкого разделения между первым и вторым этапом, или даже тремя. В простейшем случае эти действия можно сделать одной выборкой из БД.
Исследование, описанное в статье про аутентификация, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое аутентификация, авторизация, jwt, oauth2, oauth и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории информационная безопасность - Криптография и Криптоанализ. Стеганография. Защита Информации
Комментарии
Оставить комментарий
информационная безопасность - Криптография и Криптоанализ. Стеганография. Защита Информации
Термины: информационная безопасность - Криптография и Криптоанализ. Стеганография. Защита Информации