Лекция
Это продолжение увлекательной статьи про аутентификация.
...
src="/th/25/blogs/id8651/85d622bdb2a985fd21e7badeac10de2f.png" data-auto-open loading="lazy" alt="Аутентификация и авторизация" >
Полезная нагрузка 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]
В бизнесе — выдача лицензии (например: уполномоченный или авторизированный автомобильный дилер)[11].
Авторизация перевода — перевод, просмотренный и одобренный автором или сделанный с согласия автора оригинала[12]. Такой вид перевода публицистического или художественного произведения, при котором переводчик становится автором переведенного текста. Отличается значительными изменениями оригинала, далеко выходящими за рамки обычной при переводе адаптации и стилистической переработки. Переводчик может применять свои собственные творческие приемы, изменять состав героев и даже перекраивать сюжет произведения[13].
Авторизация в общедоступных сетях Wi-Fi посредством СМС.
Довольно важной задачей при разработке веб-сайтов и веб-приложений есть ограничение доступа к некоторым разделам сайта, например к панели администратора. В теории это достаточно сложный процесс, с трема составляющими - аутентификация, идентификация и авторизация (англ. authentication, identification, authorization).
Система аутентификации/авторизации в представлении разработчиков Symfony framework
Сразу после введения учетных данных (это может быть пара логин/пароль, одноразовый пароль, access token, md5-шифр, сертификат и многое другое) начинается процедура аутентификации (authentication). Она заключается в проверке подлинности. Например, сопоставить имя/пароль пользователя с учетной записью в базе данных, проверка контрольной суммы файла и т.д.
В общем случае, для процедуры аутентификации нужно либо что-то знать (например, пароль), либо иметь устройство аутентификации (например, ваш смартфон во многих современных электронных банковских системах), либо какие-то уникальных биометрические данные - отпечатки пальцев, рельеф лица, голос, радужная оболочка глаза и т.д.
Если процедура аутентификации прошла успешно, следующим шагам является идентификация. Задача идентификации - получить идентификатор пользователя в
продолжение следует...
Часть 1 Аутентификация и авторизация
Часть 2 Механизм аутентификации на основе JWT токена - Аутентификация и авторизация
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Аутентификация и авторизация
Исследование, описанное в статье про аутентификация, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое аутентификация, авторизация, jwt, oauth2, oauth и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Криптография и Криптоанализ. Стеганография. Защита Информации и информационная безопасность.
Комментарии
Оставить комментарий
информационная безопасность - Криптография и Криптоанализ. Стеганография. Защита Информации
Термины: информационная безопасность - Криптография и Криптоанализ. Стеганография. Защита Информации