Аутентификация у провайдера что это
Что такое Аутентификация: Методы и Элементы
Узнайте больше о том, для чего нужна аутентификация, и ознакомьтесь с её методами
Аутентификация (англ. authentication) — это основа безопасности любой системы, которая заключается в проверке подлинности данных о пользователе сервером.
Она не тождественна идентификации и авторизации. Эти три термина являются элементами защиты информации. Первая стадия — идентификация. На ней происходит распознавание информации о пользователе, например, логин и пароль. Вторая стадия — аутентификация. Это процесс проверки информации о пользователе. Третья стадия — авторизация. Здесь происходит проверка прав пользователя и определяется возможность доступа.
Содержание
Зачем нужна аутентификация
Аутентификация нужна для доступа к:
Элементы аутентификации
Методы аутентификации
Парольные
Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом.
Комбинированные
Этот метод говорит сам за себя. Аутентификация происходит с использованием нескольких методов, например, парольных и криптографических сертификатов. Он требует специальное устройство для считывания информации.
Биометрические
Это самый дорогостоящий метод аутентификации. Он предотвращает утечку или кражу персональной информации. Проверка проходит по физиологическим характеристикам пользователя, например, по отпечатку пальца, сетчатке глаза, тембру голоса и даже ДНК.
Информация о пользователе
Она используется для восстановления логина или пароля и для двухэтапной аутентификации, чтобы обеспечить безопасность. К этому методу относится номер телефона, девичья фамилия матери, год рождения, дата регистрации, кличка питомца, место проживания.
Пользовательские данные
Этот метод основывается на геоданных о местоположении пользователя с использованием GPS, а также использует информацию о точках доступа беспроводной связи. Недостаток заключается в том, что с помощью прокси-серверов можно подменить данные.
Классификация видов аутентификации
В зависимости от количества используемых методов
В зависимости от политики безопасности систем и уровня доверия
Чтобы защитить владельца сайта от злоумышленников, используют криптографические протоколы аутентификации.
Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.
Аутентификация на PC
Аутентификация в сети
Ресурсы
Также искали с «Аутентификация»
Оценка: 4 / 5 (18)
Начните пользоваться сервисом SendPulse прямо сегодня
Если вам интересно, что такое «✅ Аутентификация: Определение, Методы, Виды», вам может быть интересен наш сервис рассылок.
Что такое Аутентификация (Authentification): значение, типы, виды и примеры
Всем привет! Сегодня мы простыми словами поговорим про аутентификацию, авторизацию, и про то – как происходит проверка личности в сети. Аутентификация – процедура проверки подлинности, повсеместно встречающаяся в сфере информационных технологий.
Более подробно
Подлинность проверяется и на сайтах, путем сравнения добавленных в текстовое поле «Password» символов и букв с паролями, сохраненными в базе данных, и в сети – для проверки целостности файлов, документов и даже электронных писем. В масштабах современного мира без аутентификации невозможно представить и пары серьезных приложений. А потому важно разобраться, откуда взялась проверка подлинности и до каких вершин добралась в процессе развития.
Но перед стартом важно разобраться в «словах» и в том, что скрывается за «аутентификацией». И начать лучше с примеров, часто вызывающих путаницу:
А вот авторизация уже помогает определить, какие права доступа выданы субъекту, закончившему аутентификацию, и какие функции разблокируются после.
Давайте же разберемся – что же такое аутентификация? Эволюция – от простого к сложному:
HTTP Basic Authentication
Базовый и уже редко применяемый протокол аутентификации, основанный на передаче логина и пароля на конкретный сервер, привязанный к клиенту (приложениям, браузеру и сайтам) для проверки пользователей. Защищается передаваемая информация по стандарту Base64 (двоичная кодировка с помощью 64 символов ASCII), из-за чего и возникает риск столкнуться с утечками и опасностями (вроде атаки «Посредника»). При использовании незащищенных соединений передаваемые логины и пароли с легкостью перехватываются злоумышленниками на этапе передаче к серверу или уже к клиенту.
HTTP Digest Authentication
Альтернативный этап развития технологии аутентификации, связанный с добавлением к логинам и паролям дополнительного 128-битного алгоритма хэширования (генерируется специальный «отпечаток» произвольной длинны, а после – сверяется с данными, хранящимися на сервере). Из преимуществ – мошенникам сложнее подобрать конфиденциальную информацию, и все же уязвимостей достаточно для перехвата.
Forms Authentication
Промежуточная точка развития, исключающая вывод ошибок до аутентификации. У Digest и Basic при запросах на страницах защищенных ресурсов выводится стандартная ошибка о недостатке прав и возможностей, помечаемая – как 401 Unauthorized. При попытке заглянуть на недоступные страницы сайта пользователя перебросит на соседнюю страницу – где и начнется процесс проверки подлинности методом ввода логина и пароля.
В результате формируется специальный HTTP POST-запрос вместе с данными из заполненной веб-формы, и передается на серверное хранилище. Сгенерированные данные изучаются, а после – возвращаются обратно, но уже в форме идентификатора, который хранится в браузере пользователя вместе с «Cookies», и автоматически применяется на всех этапах взаимодействия с защищенным ресурсом.
Token Authentication
Отдельный этап проверки подлинности в сети, основанный на SSO – Single Sign-On, технологии, предусматривающей возможность переключения между ресурсами и приложениями без дополнительного запроса аутентифицироваться.
В Token Authentication «доказательства» (подтверждающие личность) передаются уже другому сервису-посреднику (Identity Provider), который и распределяет токены. Простейших примеров для описания процесса два: первый основан на входе в профиль через аккаунты в социальных сетях (Facebook, VK); а второй – на влиянии паспорта гражданина на остальные государственные службы. Вроде бы, документ выдали в полицейском отделении, но остальные структуры власти с подтверждением личности согласны и на дополнительную проверку уже не претендуют, и даже не пытаются сказать, – что какие-то формы недействительные.
OAuth2 & Open ID Connect.
Усовершенствованная модель аутентификации, добавляющая в цепочку к защищенным соединениям, токенам, сохраняемым в Cookies, и прочим мерам шифрования, еще и специальную поддержку в виде присутствия пользователя. Выдает токены в такой цепочке – «Open ID Connect Provider», предназначенный для проверки пользователей, дальнейшим управлением конфиденциальной информацией и выдачей соответствующего доступа (Access Token).
Причем клиенту – программе, браузеру или приложению, запрашиваемому токен – придется лишь единожды запросить у пользователя логин и пароль, в дальнейшем Cookies помогут переходить между смежными ресурсами без каких-либо дополнительных действий.
Видео
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Методы аутентификации клиентов беспроводных сетей
Аутентификация в воздухе
Существует большое количество методов аутентификации клиентов беспроводных сетей при подключении. Эти методы появлялись по мере развития различных беспроводных технологий и беспроводного оборудования. Они развивались по мере выявления слабых мест в системе безопасности. В этой статье рассматриваются наиболее распространенные методы проверки подлинности.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Открытая аутентификация
Стандарт 802.11 предлагал только два варианта аутентификации клиента: open authentication и WEP.
Open authentication-предполагает открытый доступ к WLAN. Единственное требование состоит в том, чтобы клиент, прежде чем использовать 802.11, должен отправить запрос аутентификации для дальнейшего подключения к AP (точке доступа). Более никаких других учетных данных не требуется.
В каких случаях используется open authentication? На первый взгляд это не безопасно, но это не так. Любой клиент поддерживающий стандарт 802.11 без проблем может аутентифицироваться для доступа к сети. В этом, собственно, и заключается идея open authentication-проверить, что клиент является допустимым устройством стандарта 802.11, аутентифицируя беспроводное оборудование и протокол. Аутентификация личности пользователя проводится другими средствами безопасности.
Вы, вероятно, встречали WLAN с open authentication, когда посещали общественные места. В таких сетях в основном аутентификация осуществляется через веб-интерфейс. Клиент подключается к сети сразу же, но предварительно должен открыть веб-браузер, чтобы прочитать и принять условия использования и ввести основные учетные данные. С этого момента для клиента открывается доступ к сети. Большинство клиентских операционных систем выдают предупреждение о том, что ваши данные, передаваемые по сети, не будут защищены.
Как вы понимаете, open authentication не шифрует передаваемые данные от клиента к точке доступа. В стандарте 802.11 определен Wired Equivalent Privacy (WEP). Это попытка приблизить беспроводную связь к проводному соединению.
Для кодирования данных WEP использует алгоритм шифрования RC4. Данный алгоритм шифрует данные у отправителя и расшифровывает их у получателя. Алгоритм использует строку битов в качестве ключа, обычно называемого WEP- ключом. Один кадр данных-один уникальный ключ шифрования. Расшифровка данных осуществляется только при наличии ключа и у отправителя, и у получателя.
WEP- это метод безопасности с общим ключом. Один и тот же ключ должен быть как у отправителя, так и получателя. Этот ключ размещается на устройствах заранее.
WEP-ключ также может использоваться в качестве дополнительного метода аутентификации, а также инструмента шифрования. Если клиент отправляет неправильный ключ WEP, он не подключится к точке доступа. Точка доступа проверяет знание клиентом ключа WEP, посылая ему случайную фразу вызова. Клиент шифрует фразу вызова с помощью WEP и возвращает результат точке доступа (АР). АР сравнивает шифрование клиента со своим собственным, чтобы убедиться в идентичности двух ключей WEP.
802.1x/EAP
При наличии только open authentication и WEP, доступных в стандарте 802.11, требовался более безопасный метод аутентификации. Аутентификация клиента обычно включает в себя отправку запроса, получение ответа, а затем решение о предоставлении доступа. Помимо этого, возможен обмен ключами сессии или ключами шифрования в дополнение к другим параметрам, необходимым для клиентского доступа. Каждый метод аутентификации может иметь уникальные требования как уникальный способ передачи информации между клиентом и точкой доступа.
Вместо того чтобы встроить дополнительные методы аутентификации в стандарт 802.11, была выбрана более гибкая и масштабируемая структура аутентификации-разработан расширяемый протокол аутентификации (EAP). Как следует из его названия, EAP является расширяемым и не состоит из какого-либо одного метода аутентификации. Вместо этого EAP определяет набор общих функций, которые применяют фактические методы аутентификации, используемые для аутентификации пользователей.
EAP имеет еще одно интересное качество: он интегрируется со стандартом управления доступом на основе портов стандарта IEEE 802.1X. Когда порт стандарта 802.1X включен, он ограничивает доступ к сетевому носителю до тех пор, пока клиент не аутентифицируется. Это означает, что беспроводной клиент способен связываться с точкой доступа, но не сможет передавать данные в другую часть сети, пока он успешно не аутентифицируется.
Open authentication и WEP аутентификация беспроводных клиентов выполняется локально на точке доступа. В стандарте 802.1 x принцип аутентификации меняется. Клиент использует открытую аутентификацию для связи с точкой доступа, а затем фактический процесс аутентификации клиента происходит на выделенном сервере аутентификации. На рисунке 1 показана трехсторонняя схема стандарта 802.1x, состоящая из следующих объектов:
На рисунке клиент подключен к точке доступа через беспроводное соединение. AP представляет собой Аутентификатор. Первичное подключение происходит по стандарту open authentication 802.11. Точка доступа подключена к WLC, который, в свою очередь, подключен к серверу аутентификации (AS). Все в комплексе представляет собой аутентификацию на основе EAP.
Контроллер беспроводной локальной сети является посредником в процессе аутентификации клиента, контролируя доступ пользователей с помощью стандарта 802.1x, взаимодействуя с сервером аутентификации с помощью платформы EAP.
Далее рассмотрим некоторые вариации протокола защиты EAP
Первые попытки устранить слабые места в протоколе WEP компания Cisco разработала собственный метод беспроводной аутентификации под названием Lightweight EAP (LEAP). Для проверки подлинности клиент должен предоставить учетные данные пользователя и пароля.
Сервер проверки подлинности и клиент обмениваются челендж сообщениями, которые затем шифруются и возвращаются. Это обеспечивает взаимную аутентификацию. Аутентификация между клиентом и AS осуществляется только при успешной расшифровке челендж сообщений.
На тот момент активно использовалось оборудование, работавшее с WEP- протоколом. Разработчики протокола LEAP пытались устранить слабые места WEP применением динамических, часто меняющихся ключей WEP. Тем не менее, метод, используемый для шифрования челендж сообщений, оказался уязвимым. Это послужило поводом признать протокол LEAP устаревшим. Существуют организации, которые все еще используют данный протокол. Не рекомендуется подключаться к таким сетям.
EAP-FAST
EAP-FAST (Flexible Authentication by Secure Tunneling) безопасный метод, разработанный компанией Cisco. Учетные данные для проверки подлинности защищаются путем передачи зашифрованных учетных данных доступа (PAC) между AS и клиентом. PAC- это форма общего секрета, который генерируется AS и используется для взаимной аутентификации. EAP-FAST- это метод состоящий из трех последовательных фаз:
Обратите внимание, что в EAP-FAST происходят два отдельных процесса аутентификации-один между AS и клиентом, а другой с конечным пользователем. Они происходят вложенным образом, как внешняя аутентификация (вне туннеля TLS) и внутренняя аутентификация (внутри туннеля TLS).
Данный метод, основанный на EAP, требует наличие сервера RADIUS. Данный сервер RADIUS должен работать как сервер EAP-FAST, чтобы генерировать пакеты, по одному на пользователя.
Аналогично EAP-FAST, защищенный метод EAP (PEAP) использует внутреннюю и внешнюю аутентификацию, однако AS предоставляет цифровой сертификат для аутентификации себя с клиентом во внешней аутентификации. Если претендент удовлетворен идентификацией AS, то они строят туннель TLS, который будет использоваться для внутренней аутентификации клиента и обмена ключами шифрования.
Цифровой сертификат AS состоит из данных в стандартном формате, идентифицирующих владельца и «подписанных» или подтвержденных третьей стороной. Третья сторона известна как центр сертификации (CA) и известна и доверяет как AS, так и заявителям. Претендент также должен обладать сертификатом CA только для того, чтобы он мог проверить тот, который он получает от AS. Сертификат также используется для передачи открытого ключа на видном месте, который может быть использован для расшифровки сообщений из AS.
Обратите внимание, что только AS имеет сертификат для PEAP. Это означает, что клиент может легко подтвердить подлинность AS. Клиент не имеет или не использует свой собственный сертификат, поэтому он должен быть аутентифицирован в туннеле TLS с помощью одного из следующих двух методов:
EAP-TLS
PEAP использует цифровой сертификат на AS в качестве надежного метода для аутентификации сервера RADIUS. Получить и установить сертификат на одном сервере несложно, но клиентам остается идентифицировать себя другими способами. Безопасность транспортного уровня EAP (EAP-TLS) усиливает защиту, требуя сертификаты на AS и на каждом клиентском устройстве.
С помощью EAP-TLS AS и клиент обмениваются сертификатами и могут аутентифицировать друг друга. После этого строится туннель TLS, чтобы можно было безопасно обмениваться материалами ключа шифрования.
EAP-TLS считается наиболее безопасным методом беспроводной аутентификации, однако при его реализации возникают сложности. Наряду с AS, каждый беспроводной клиент должен получить и установить сертификат. Установка сертификатов вручную на сотни или тысячи клиентов может оказаться непрактичной. Вместо этого вам нужно будет внедрить инфраструктуру открытых ключей (PKI), которая могла бы безопасно и эффективно предоставлять сертификаты и отзывать их, когда клиент или пользователь больше не будет иметь доступа к сети. Это обычно включает в себя создание собственного центра сертификации или построение доверительных отношений со сторонним центром сертификации, который может предоставлять сертификаты вашим клиентам.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Не стоит создавать собственные решения для аутентификации пользователей
Автор статьи, перевод которой мы публикуем, предлагает прекратить писать собственный код для аутентификации пользователей. Он полагает, что пришло время внедрять более безопасные решения, которые, если даже не говорить о других их плюсах, позволяют экономить время и деньги.
В большинстве приложений необходима некая подсистема аутентификации пользователей. Может быть вы — программист, работающий в крупной компании над бизнес-приложениями, в которых требуется ограничить доступ к неким материалам неавторизованным сотрудникам компании и нужно проверять разрешения этих пользователей. Возможно вы пишете код новой SaaS-платформы, и вам нужно, чтобы её пользователи могли бы создавать учётные записи и управлять ими.
В обоих этих случаях, да и во многих других, вы, вероятнее всего, начнёте работу над приложением с создания подсистем аутентификации и средств для управления пользователями. То есть, как минимум, создадите форму регистрации и страницу для входа в систему. Подсистемы аутентификации — это именно то, что чаще всего просят реализовать веб-разработчиков, занятых некими проектами. Но, несмотря на это, такие подсистемы, это ещё и то, на что обычно обращают очень мало внимания.
Разработка безопасной системы аутентификации пользователей — это по-настоящему сложная задача. Она гораздо масштабнее, чем многие думают. Эту задачу очень легко решить неправильно. Хуже того: ошибки при создании подсистем аутентификации могут повлечь за собой катастрофические последствия. В базовую структуру систем аутентификации и управления пользователями входит всего несколько форм. Из-за этого создание подобных систем может показаться весьма простым делом. Но, как известно, дьявол кроется в деталях. Нужно немало потрудиться для того чтобы сделать такие системы безопасными (и, когда это возможно или даже необходимо, учесть в них требования конфиденциальности персональных данных).
IDaaS
К счастью, у современного веб-разработчика нет необходимости в развёртывании собственной системы для аутентификации пользователей и для управления ими. Сейчас, в 2020 году, существует множество хороших IDaaS-решений (Identity as a Service, идентификация как сервис). Применение таких решения значительно упрощает оснащение веб-проектов возможностями по аутентификации пользователей.
Вот несколько популярных IDaaS-проектов (в алфавитном порядке): Auth0, Azure AD, Google Identity Platform и Okta.
Кроме того, существуют поставщики идентификационной информации, основанной на чём-то наподобие учётных записей пользователей социальных сетей. Это, например, Apple, Facebook, GitHub, Twitter. Разработчикам очень легко внедрять в свои проекты возможности этих систем. Тот, кто работает с провайдерами аутентификации, может очень быстро создать соответствующую подсистему приложения, имеющую доступ к большому массиву данных о пользователях. Но иногда взаимодействие проекта с провайдерами может иметь негативное влияние на конфиденциальность данных пользователей.
На самом деле, нельзя назвать реальную причину, по которой некоему разработчику не стоит пользоваться услугами поставщика идентификационной информации. Работа с подобным сервисом позволит сэкономить массу времени, которое можно будет потратить на разработку самого приложения. Эти сервисы дают разработчику, без каких-либо существенных усилий с его стороны, множество возможностей. А самое важное здесь то, что они гораздо безопаснее, чем некое самописное решение.
Чем больше пользователей — тем безопаснее решение
Большинство поставщиков идентификационной информации предлагаю дополнительные возможности, касающиеся безопасности. Такие, как поддержка многофакторной аутентификации (MFA, multi-factor authentication), поддержка сертификатов безопасности или ключей (в том числе — U2F, FIDO2, WebAuthn и прочее подобное).
Не стоит недооценивать важность этих технологий. В соответствии с отчётом Microsoft, включение MFA позволяет предотвратить до 99,9% атак на учётные записи.
Однако в деле использования сторонних сервисов аутентификации вместо собственных решений есть ещё один аспект, менее известный. А именно, речь идёт о том, что благодаря очень большому количеству пользователей, с которыми работают подобные сервисы, они могут отслеживать паттерны поведения злоумышленников и легче предотвращать атаки на учётные записи.
Большие провайдеры, благодаря тому, что у них имеются миллионы пользователей, которые ежедневно выполняют бесчисленное множество входов в систему, собирают достаточно данных для построения моделей, основанных на возможностях искусственного интеллекта. Такие модели позволяют лучше идентифицировать подозрительные паттерны поведения.
Например, предположим, один из ваших пользователей, живущий в Канаде, входит в систему из дома. А через два часа вход в тот же аккаунт выполняется из Украины. Сервисы поставщика идентификационной информации способны счесть такое поведение подозрительным и могут либо сразу запретить вход, либо предложить пользователю пройти дополнительную верификацию (например, с использованием MFA-токена). Они, кроме того, могут уведомлять пользователей, которые подверглись атаке, или системных администраторов, а возможно — и тех, и других.
Распространённые возражения, высказываемые об использовании сторонних сервисов аутентификации
▍На самом деле, не так уж и сложно создать собственную систему для аутентификации пользователей и для управления ими
Формы для регистрации в проекте и для входа в него — это лишь одна сторона «медали» системы аутентификации. Разработчику, создавая подобную систему, придётся решить гораздо больше задач, чем разработка пары форм.
Для начала, нужно решить дополнительные задачи, связанные с управлением пользователями. Такие, как применение политик безопасности паролей, создание системы подтверждения адресов электронной почты или номеров телефонов, разработка механизмов безопасного сброса паролей. Правда, в том, что касается управления паролями, прошу всех прислушаться к NIST и не оснащать систему неотключаемым механизмом, работа которого направлена на то, чтобы срок действия паролей истекал бы по прошествии определённого времени. Не стоит и принуждать пользователей к тому, чтобы они создавали бы «креативные» пароли, содержащие символы верхнего и нижнего регистра, специальные символы и так далее.
При проектировании подобных систем нужно держать в голове массу мелких деталей. При этом тут очень легко совершить ошибки. Огромные компании были замечены в том, что они, например, не хешируют пароли в своих базах данных (или хешируют их неправильно), в том, что они случайно сбрасывают пароли в лог-файлы в виде обычного текста, в том, что их механизмы сброса паролей очень легко взломать, пользуясь методами социальной инженерии. Этот список можно продолжать.
То, что правильное управление паролями, это — непростая задача, не должно никого удивлять. А вы знали о том, что управление именами пользователей — это тоже сложно? Например, тот факт, что имена пользователей выглядят одинаково, ещё не означает, что система, при их сравнении, сочтёт их таковыми. В этом выступлении 2018 года высказаны ещё некоторые интересные идеи, касательно того, что может пойти не так при работе с такими «простыми» сущностями, как имена пользователей.
И наконец, стоит отметить, что веб-проекты могут многое выиграть от применения дополнительных мер безопасности, предлагаемых поставщиками идентификационной информации. Сюда входят, например, многофакторная аутентификация и токены безопасности.
▍Использование сервисов аутентификации пользователей не всегда бесплатно, особенно — для крупных проектов
А знаете о том, что ещё, связанное с безопасностью, не является бесплатным? Необходимость возмещать ущерб от взломов. Этот ущерб может быть выражен в денежной форме, если те, кого взломали, понесли какие-то потери, это может быть время, потраченное на срочную доработку собственного проекта, это, что так же неприятно, как и другие последствия взломов, потеря доверия пользователей.
И даже если не говорить о взломах, реализация безопасной системы аутентификации и управление ей, работа с базой данных пользователей и решение прочих подобных задач, предусматривает трату времени и ресурсов. Это — и ресурсы, уходящие на разработку системы, и ресурсы, необходимые на её поддержание в работоспособном состоянии.
▍Я — очень опытный разработчик, поэтому знаю о том, как создать безопасную систему аутентификации
Для начала — примите поздравления. Дело в том, что настоящие знания о том, как создаются безопасные системы аутентификации, есть у гораздо меньшего числа разработчиков, чем вы думаете, и чем можете ожидать.
Но если вы и правда — опытнейший разработчик, тогда, вполне возможно, ваше время лучше потратить на реализацию других частей приложения, которые приносят пользователям этого приложения какую-то ощутимую пользу.
Или, если вы и правда хотите создать собственную систему аутентификации, то вы можете поразмыслить о поступлении на работу в компанию, вроде Microsoft, Auth0 или Facebook с целью улучшения их систем идентификации пользователей.
▍Я хочу держать под контролем пользователей моего проекта
Я, рассматривая данную идею, сразу хочу задать вам вопрос: «А зачем вам это?». Вполне возможно то, что вам это по-настоящему не нужно. Ну, если только вы не разрабатываете новый Facebook. В таком случае данные о пользователях — это ваш самый главный актив, и чем больше таких данных вы соберёте, тем лучше.
Кроме того, чем больше данных о пользователях вы собираете — тем выше вероятность того, что вам придётся потратиться на то, чтобы привести свою систему в соответствие с некими правилами, вроде GDPR. Далее, если вы храните большие объёмы данных о пользователях, это может утяжелить последствия взломов и потребовать дополнительных расходов на устранения этих последствий.
Надо отметить, что большинство вышеперечисленных специализированных решений для аутентификации дают вам достаточно подробные сведения о пользователях и об их действиях.
Если вы рассматриваете вариант использования разработанного кем-то сервиса аутентификации, который собираетесь хостить у себя, то знайте, что применение таких сервисов сопряжено с определёнными сложностями. Возможно, вы хотите использовать подобный сервис для того чтобы в будущем обеспечить себе возможность перехода на что-то другое. Учитывайте, что подобные системы достаточно сложно поддерживать, и то, что сравнительно небольшое количество регистрируемых в них пользователей часто означает то, что владельцы таких систем не могут эффективно использовать дополнительные механизмы безопасности.
С чего начать?
Надеюсь, я убедил вас в том, что аутентификация пользователей — это задача, которую лучше всего решать силами специализированного поставщика идентификационной информации. Вот как это сделать.
Для начала — хорошая новость. Она заключается в том, что все четыре вышеперечисленных провайдера (Auth0, Azure AD, Google Identity Platform, Okta), да и многие другие, используют одни и те же протоколы: OpenID Connect / OAuth 2.0. Это — современные стандартные протоколы, клиентские библиотеки для поддержки которых существуют практически для всех языков программирования и фреймворков.
Для того чтобы приступить к использованию услуг какого-нибудь поставщика идентификационной информации, нужно, если не вдаваться в детали, сделать следующее:
Тот же токен содержит некоторые сведения о пользователе. Набор этих сведений зависит от используемого сервиса аутентификации. Обычно это — имя пользователя, адрес его электронной почты, его идентификатор.
Приложение может использовать эти сведения для идентификации пользователя. Вы можете использовать идентификатор пользователя для того чтобы обращаться к связанным с ним данным, хранящимся в вашем приложении.
Как уже было сказано, JWT-токены криптографически подписаны. Поэтому вы, проверяя подпись токена, можете быть уверенными в том, что никто не подменил сведения о пользователе, которые содержатся в токене.
Использование OpenID Connect в клиент-серверных приложениях
То, как именно в конкретном приложении будет использоваться механизм OpenID Connect, сильно зависит от того, с использованием какого языка и фреймворка создано приложение.
На сайте jwt.io можно найти исчерпывающий список библиотек, которые можно использовать для верификации JWT-токенов.
Для некоторых стеков технологий, кроме того, можно воспользоваться решениями более высокого уровня. Например — это, в среде Node.js/Express, express-jwt или passport.
Использование OpenID Connect на статических сайтах или в нативных приложениях
Статические веб-приложения (их ещё называют «JAMstack-сайтами») и нативные приложения (то есть — настольные или мобильные приложения) тоже могут пользоваться OpenID Connect, но делается это немного не так, как в случае с обычными веб-проектами. В спецификации OAuth 2.0 это называется «implicit flow», или получение токена доступа напрямую от пользователя.
При таком подходе не нужно использовать механизм, в котором применяется секретный ключ (Client Secret). Дело в том, что приложение выполняется на клиенте, поэтому не существует безопасного способа распространения подобных ключей. Здесь применяется следующая последовательность действий:
При разработке клиент-серверных проектов, таких, как статические веб-ресурсы или нативные приложения, важно обеспечить то, чтобы токен был бы подписан с использованием RSA-SHA256 (в заголовке токена alg должно быть записано RS256 ). Речь идёт об использовании механизма асимметричного шифрования: поставщик идентификационной информации подписывает токены с использованием секретного ключа, а приложение может проверить токен с использованием публичного ключа. Ещё один распространённый алгоритм, применяемый для подписи токенов, это HMAC-SHA256 (или HS256 ). Тут используется симметричное шифрование, для подписи и проверки токенов применяется один и тот же ключ. Проблема тут в том, что нельзя организовать безопасное хранение подобных ключей в клиентских приложениях.
Серверный API, получив запрос, ищет в нём токен. Обнаружив токен, сервер снова его верифицирует. Если токен успешно проходит проверку (и если срок его действия ещё не истёк), сервер может счесть пользователя аутентифицированным и может воспользоваться идентификатором пользователя, взятым из токена.
Какие механизмы аутентификации пользователей применяете вы?