Токен безопасности, или секьюрити токен (англ. Security token) – это физическое или цифровое устройство, которое обеспечивает двухфакторную аутентификацию (2FA) для пользователя, чтобы подтвердить его личность в процессе входа в систему. Обычно он используется как форма идентификации для физического доступа или как метод доступа к компьютерной системе. Токен может быть предметом или картой, которая отображает или содержит информацию о безопасности пользователя и может быть проверена системой.
Токены безопасности могут использоваться вместо традиционных паролей или в дополнение к ним. Чаще всего они используются для доступа к компьютерным сетям, но также могут обеспечивать физический доступ к зданиям и выступать в качестве электронных подписей для документов.
Как работают токены безопасности?
Токен безопасности обеспечивает аутентификацию для доступа к системе через любое устройство, генерирующее пароль. Это может быть смарт-карта, USB-ключ, мобильное устройство или RFID-карта. Устройство генерирует новый пароль при каждом использовании, поэтому токен безопасности можно использовать для входа в компьютер или виртуальную частную сеть, введя пароль, сгенерированный токеном, в приглашение.
Технология токенов безопасности основана на использовании устройства, которое генерирует случайное число, шифрует его и отправляет на сервер с информацией для аутентификации пользователя. Затем сервер отправляет обратно зашифрованный ответ, который может быть расшифрован только устройством. Устройство повторно используется для каждой аутентификации, поэтому серверу не нужно хранить информацию об имени пользователя или пароле, делая систему менее уязвимой для взлома.
Что такое Security Token Offering (STO)
Согласно широко распространенному мнению, Security Token Offering (STO) является следующим эволюционным шагом после бума Initial Coin Offering (ICO), определяющим вектор развития индустрии в сторону более регулируемого и прозрачного рынка. Однако STO и ICO — это два разных механизма привлечения инвестиций, предназначенные для разных ситуаций.
В первую очередь, STO предполагают выпуск цифровых активов в полном соответствии с требованиями законодательства о ценных бумагах. Это должно обеспечить более высокую степень защиты прав инвесторов и снижение регулятивных рисков для эмитентов токенов. Кроме того, STO ориентируются на другую целевую аудиторию — участвовать в подобном размещении могут исключительно профессиональные (аккредитованные) инвесторы.
В данную категорию, согласно законодательству США, входят лица, отвечающие как минимум одному из перечисленных ниже требований:
- Годовой доход в размере более $200 000 на одного человека или $300 000 для супружеской пары, поддерживаемый в течение последних двух лет и прогнозируемый в текущем году, в котором лицо планирует осуществить инвестиции;
- Чистые активы в размере свыше $1 млн, в которые не входит стоимость недвижимости, в которой лицо проживает на постоянной основе;
- Организация, которая имеет активы на сумму свыше $5 млн, например, венчурный или целевой фонд;
- Компания, все члены которой являются аккредитованными инвесторами.
Кроме того, существует масса технических деталей, которые инвестору необходимо знать для правильного участия в STO, а организаторам — для привлечения средств. В частности, при проведении STO в США эмитенты должны принимать во внимание Закон о ценных бумагах от 1933 года, а именно несколько его положений: положение D, положение A+ и положение S. Они описывают различные сценарии, при которых компании могут предлагать инвесторам ценные бумаги (security-токены).
Типы токенов безопасности
Для защиты различных активов и приложений используются несколько типов токенов безопасности. К ним относятся следующие:
- Одноразовые пароли (OTP). Одной из форм токена цифровой безопасности являются одноразовые пароли. Они действительны только для одного сеанса входа в систему, то есть они используются один раз и никогда больше. После первоначального использования сервер аутентификации уведомляется о том, что OTP не следует использовать повторно. OTP обычно генерируются с использованием криптографического алгоритма из общего секретного ключа, состоящего из двух уникальных и случайных элементов данных. Один элемент – это случайный идентификатор сеанса, а другой – секретный ключ.
- Отключенные токены. Это форма цифрового токена безопасности, который физически или логически не подключается к компьютеру. Устройство может генерировать OTP или другие учетные данные. Приложение для ПК, которое отправляет текстовое сообщение на смартфон, которое пользователь должен ввести при входе в систему, использует отключенный токен.
- Подключенные токены. Подключенный токен – это физический объект, который напрямую подключается к компьютеру или сенсору. Устройство считывает подключенный токен и предоставляет или запрещает доступ. YubiKey – это пример подключенного токена.
- Бесконтактные токены. Бесконтактные токены образуют логическое соединение с компьютером, не требуя физического соединения. Эти токены подключаются к системе по беспроводной сети и разрешают или запрещают доступ через это соединение. Например, Bluetooth часто используется как метод установления соединения с бесконтактным токеном.
- Программные токены системы единого входа (SSO). Программные токены системы единого входа хранят цифровую информацию, такую как имя пользователя или пароль. Они позволяют людям, которые используют несколько компьютерных систем и несколько сетевых служб, входить в каждую систему без необходимости запоминать несколько имен пользователей и паролей.
- Программируемые токены. Программируемый токен безопасности многократно генерирует уникальный код, действительный в течение определенного периода времени, часто 30 секунд, для предоставления доступа пользователю. Например, AWS Security Token Service – это приложение, которое генерирует коды 2FA, необходимые администраторам информационных технологий для доступа к некоторым облачным ресурсам Amazon Web Services.
Авторизация и аутентификация для всех и каждого, часть 2
Перевод второй части статьи «Authorization and Authentication For Everyone».
В первой части мы рассмотрели основные термины, а также подробно остановились на теме делегированного доступа. Продолжаем разбираться.
Проблема входа в систему
После того как OAuth 2.0 обеспечил возможность доступа к сторонним API, создатели приложений также захотели, чтобы их пользователи могли логиниться при помощи других аккаунтов. Возьмем пример. Скажем, приложение HireMe123 хочет, чтобы пользователь MyCalApp мог логиниться в HireMe123, используя аккаунт MyCalApp — несмотря на то, что в самом HireMe123 у него нет аккаунта.
Но, как уже говорилось, OAuth 2.0 — это про делегированный доступ. Это НЕ протокол аутентификации. Тем не менее, это не остановило людей в их попытках использовать OAuth 2.0 именно с целью аутентификации, и это породило проблемы.
Проблемы, связанные с использованием токенов доступа для аутентификации
Если HireMe123 полагает, что успешный вызов API MyCalApp при помощи токена доступа означает, что пользователь может считаться аутентифицированным в HireMe123, мы сталкиваемся с проблемами. Дело в том, что у нас нет возможности проверить, был ли токен доступа выпущен для данного человека.
Например:
- Кто-нибудь мог украсть токен доступа другого пользователя.
- Токен доступа мог быть получен от другого клиента (не HireMe123) и вставлен в HireMe123.
Эта проблема получила название confused deputy. HireMe123 не знает, откуда пришел токен и для кого он был выпущен. Давайте припомним: аутентификация — это проверка, действительно ли пользователь является тем, за кого себя выдает. То, что HireMe123 может использовать токен доступа для доступа к API, не дает ему оснований полагать, что пользователь действительно является тем, кем назвался.
Как уже говорилось, это никого не остановило и люди продолжали использовать OAuth 2.0 и токены доступа не по назначению (т. е., для аутентификации). В связи с этим быстро стала очевидной необходимость формализовать аутентификацию поверх OAuth 2.0, чтобы позволить логиниться при помощи сторонних приложений и при этом не допускать пробоев в безопасности.
OpenID Connect
Это привело нас к спецификации под названием OpenID Connect (OIDC).
OIDC это спецификация поверх OAuth 2.0, которая говорит, как аутентифицировать пользователей. Стандарты OIDC разрабатываются OpenID Foundation (OIDF).
OIDC — это слой идентификации для аутентификации пользователей при помощи сервера авторизации.
Вы помните, что сервер авторизации выпускает токены. Токены — это закодированные кусочки данных для передачи информации между разными сторонами (такими как сервер авторизации, приложение или API). В случае OIDC и аутентификации сервер авторизации выпускает ID-токены.
ID-токены
ID-токены предоставляют информацию о событии аутентификации и идентифицируют пользователя. ID-токены предназначены для клиента. Они имеют фиксированный формат, понятный для клиента: клиент может извлечь идентифицирующую информацию из токена и таким образом аутентифицировать пользователя.
OIDC декларирует фиксированный формат для ID-токенов —
JSON Web Token (JWT)
JSON Web Tokens (JWT, иногда произносится как «джот») составляются из трех URL-безопасных строковых сегментов, соединенных точками.
Заголовок JWT
Первый сегмент токена это заголовок. Он может выглядеть примерно так:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
Заголовок токена это JSON-объект, содержащий алгоритм подписи и тип токена. Он зашифрован при помощи алгоритма base64Url (бинарные данные, представленные в виде текста).
В расшифрованном виде это выглядит примерно так:
{ «alg»: «RS256», «typ»: «JWT» }
Полезная нагрузка JWT
Второй сегмент токена — полезная нагрузка. Выглядеть этот сегмент может так:
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0
Это объект JSON, содержащий заявления (claims) — предложения о пользователе и событии аутентификации. Например:
{ «sub»: «1234567890», «name»: «John Doe», «admin»: true, «iat»: 1516239022 }
Этот сегмент тоже base64Url-зашифрован.
Крипто-сегмент
Последний сегмент — это подпись или данные шифрования. JWT подписываются, чтобы их нельзя было модифицировать при пересылке. Когда сервер авторизации выпускает токен, он подписывает его при помощи ключа.
Получая ID-токен, клиент проверяет подпись (тоже при помощи ключа).
(При использовании асимметричного алгоритма для подписи и проверки используются разные ключи. В таком случае только у сервера авторизации есть возможность подписывать токены).
Не переживайте, если все это кажется запутанным. Детали того, как все работает, не должны вас беспокоить или мешать эффективно использовать сервер авторизации с аутентификацией на основе токенов.
Заявления
Теперь, когда мы знаем анатомию JWT, давайте остановимся на заявлениях (claims) — тех самых предложениях из сегмента полезной нагрузки токена. Как следует из самого их названия, ID-токены предоставляют идентифицирующую информацию, а содержится она в заявлениях.
Заявления аутентификации
Начнем с предложений, касающихся события аутентификации. Вот несколько примеров таких заявлений:
{ «iss»: «https://{you}.authz-server.com», «aud»: «RxHBtq2HL6biPljKRLNByqehlKhN1nCx», «exp»: 1570019636365, «iat»: 1570016110289, «nonce»: «3yAjXLPq8EPP0S», … }
Среди необходимых заявлений об аутентификации в ID-токенах можно назвать:
- iss (issuer): сторона, генерирующая JWT, т. е., сервер авторизации;
- aud (audience): список получателей JWT. Для ID-токенов это клиентский идентификатор приложения, получающего токен;
- exp (expiration time): время в формате Unix Time, определяющее момент, когда токен станет не валидным (expiration);
- iat (issued at time): время выпуска ID-токена (тоже в формате Unix Time).
nonce привязывает запрос авторизации клиента к получаемому токену. По сути это криптографически случайная строка, которую клиент создает и отсылает вместе с запросом авторизации. Сервер авторизации помещает nonce в токен, который отсылает назад приложению. Приложение проверяет, совпадает ли nonce в токене с тем, который был послан с запросом авторизации. Таким образом приложение может проверить, что токен поступил именно из того места, откуда запрашивался.
Заявления идентичности
Заявления также включают предложения о конечном пользователе. Вот несколько примеров таких заявлений:
{ «sub»: «google-oauth2|102582972157289381734», «name»: «Kim Maida», «picture»: «https://gravatar[…]», «twitter»: «https://twitter.com/KimMaida», «email»: «[email protected]», … }
Среди стандартных заявлений профиля в ID-токенах можно назвать:
- sub (subject): уникальный идентификатор пользователя (указывается обязательно);
- email;
- email_verified;
- birthdate (дата рождения).
Итак, мы прошли краткий курс по важным спецификациям (OAuth 2.0 и OpenID Connect). Теперь давайте посмотрим, как можно применить эти знания в работе.
Аутентификация при помощи ID-токенов
Давайте посмотрим, как происходит OIDC-аутентификация.
Примечание. Учитывайте, что это упрощенная схема. В зависимости от архитектуры вашей системы у вас будет несколько других потоков.
Рассмтариваемые нами сущности: браузер, приложение, запущенное в браузере, и сервер авторизации. Когда пользователь хочет войти в систему (залогиниться в приложении), это приложение отсылает запрос авторизации на сервер авторизации. Пользовательские логин и пароль проверяются сервером авторизации. Если все сходится, сервер выпускает ID-токен для приложения.
Затем клиентское приложение расшифровывает ID-токен (JWT) и проверяет его. В проверку входит проверка подписи, а также заявлений:
- issuer (iss): выпущен ли токен именно тем сервером авторизации, от которого мы ждали ответа?
- audience (aud): является ли наше приложение тем получателем, для которого был выпущен токен?
- expiration (exp): не истек ли срок годности этого токена?
- nonce (nonce): можем ли мы привязать этот токен к запросу авторизации, который мы посылали?
Когда мы установили аутентичность ID-токена, пользователь считается аутентифицированным. Также у нас есть доступ к заявлениям идентичности, благодаря чему мы знаем, кем является наш пользователь.
Итак, пользователь аутентифицирован. Время взаимодействовать с API.
Доступ к API при помощи токенов доступа
Выше мы уже немного поговорили о токенах доступа — когда рассматривали, как работает делегированный доступ с использованием OAuth 2.0 и серверов авторизации. Теперь давайте разберем все это подробнее. Для этого вернемся к нашему сценарию с HireMe123 и MyCalApp.
Токены доступа
Токены доступа используются для предоставления доступа к ресурсам. Благодаря токену доступа, выпущенному сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.
В отличие от ID-токенов, которые OIDC определяет как JSON веб-токены, токены доступа не имеют четко определенного формата. Они не обязательно являются JWT. Тем не менее, во многих решениях для токенов доступа все же используются JWT, потому что этот формат позволяет валидацию.
Токены доступа непрозрачны для клиента
Токены доступа предназначаются для API ресурса и важно, чтобы они были непрозрачны для клиента. Почему?
Токены доступа могут измениться в любой момент. У них должно быть короткое время устаревания, чтобы пользователь мог часто получать новые. Также они могут выпускаться повторно, чтобы дать возможность доступа к другим API или с другими правами. В клиентском приложении ни в коем случае не должно быть кода, полагающегося на содержимое токена доступа. Подобный код будет слишком хрупким и практически гарантированно сломается.
Доступ к API ресурса
Допустим, мы хотим использовать токен доступа для вызова API одностраничного приложения. Как это происходит?
Выше мы рассматривали процесс аутентификации. Предположим, что пользователь залогинился в наше JS-приложение в браузере. Это приложение отсылает запрос авторизации к серверу авторизации, запрашивая токен доступа для вызова API.
Затем, когда наше приложение хочет вступить во взаимодействие с этим API, мы прилагаем токен доступа к заголовку запроса, вот так:
# HTTP request headers Authorization: ‘Bearer eyj[…]’
Авторизованный запрос отсылается к API, который проверяет токен при помощи промежуточного ПО. Если все сходится, API возвращает данные (например, JSON) приложению, запущенному в браузере.
Это все хорошо, но выше мы упоминали, что OAuth решает проблему чрезмерных прав доступа. Как это происходит?
Делегирование с областью видимости
Как API узнает, какой уровень доступа нужно дать приложению? Это определяется путем установления области видимости (scopes).
Область видимости «ограничивает, что именно приложение может делать в интересах пользователя». Она не позволяет выдать права, которых у пользователя уже нет. Например, если пользователь MyCalApp не имеет права создавать новые корпоративные аккаунты, область видимости гарантирует, что HireMe123 тоже не позволит пользователю создавать новые корпоративные аккаунты.
Области видимости делегируют контроль доступа самому API или ресурсу. За соответствие областей видимости правам пользователя отвечает API.
Давайте рассмотрим это на примере.
Я использую приложение HireMe123. HireMe123 хочет получить доступ к стороннему API MyCalApp для создания события в календаре от моего имени. Приложение HireMe123 уже запросило токен доступа к MyCalApp на сервере авторизации MyCalApp. В этом токене содержится важная информация:
- sub: (мой пользовательский ID в MyCalApp);
- aud: MyCalAppAPI (этот токен создан для доступа к API MyCalApp);
- scope: write:events (область видимости предполагает, что HireMe123 может использовать API для записи событий в моем календаре).
HireMe123 посылает запрос к API MyCalApp с токеном доступа в заголовке авторизации. Когда API MyCalApp получает этот запрос, он видит, что в нем установлена область видимости write:events.
Но на MyCalApp содержатся аккаунты с календарями сотен тысяч пользователей. Поэтому, чтобы убедиться, что этот запрос от HireMe123 будет касаться только моих прав создавать события в моем аккаунте, промежуточное ПО API MyCalApp должно проверить не только область видимости, но и sub — идентификатор субъекта.
В контексте делегированной авторизации области видимости обозначают, что именно приложение сможет делать от имени пользователя. Это подмножество прав пользователя в целом.
Проверка согласия
Помните, мы говорили, что сервер авторизации спрашивает пользователя HireMe123, согласен ли он разрешить HireMe123 воспользоваться правами пользователя для доступа к MyCalApp?
Этот диалог выглядит примерно так:
HireMe123 может попросить предоставить ему самые разные права, на пример:
- write:events (запись событий)
- read:events (чтение событий)
- read:settings (чтение настроек)
- write:settings (запись настроек)
- и т. д.
В целом, следует избегать давать разрешения на чисто пользовательские действия. Области видимости предназначены для прав, делегированных приложениям. Но если ваш сервер авторизации имеет функционал для контроля доступа на основе ролей (Role-Based Access Control, RBAC), вы можете устанавливать разные области видимости для разных пользователей.
При помощи RBAC на сервере авторизации можно установить разные права для разных групп пользователей. После этого сервер авторизации при выпуске токенов доступа сможет включать в scopes указание ролей пользователей.
Итоги
Мы рассмотрели очень много материала, но это даже близко не все, что можно было рассмотреть. Тем не менее, я надеюсь, что этот краткий курс по идентичности, авторизации и аутентификации будет вам полезен.
Преимущества токена безопасности
Хотя это правда, что пароли и идентификаторы пользователей по-прежнему являются наиболее широко используемой формой аутентификации, токены безопасности являются более безопасным вариантом для защиты сетей и цифровых систем. Проблема с паролями и идентификаторами пользователей в том, что они не всегда безопасны. Злоумышленники продолжают совершенствовать методы и инструменты для взлома паролей, делая пароли уязвимыми. Данные паролей также могут быть доступны или украдены в результате утечки данных. Кроме того, пароли часто легко угадать, обычно потому, что они основаны на легко обнаруживаемой личной информации.
С другой стороны, токены безопасности используют уникальный для пользователя физический или цифровой идентификатор. Большинство форм относительно просты в использовании и удобны.
Смена PIN-кода на токене
Для обеспечения информационной безопасности каждый токен обладает паролем — PIN-кодом.
По умолчанию токен имеет стандартный PIN-код:
- PIN-код пользователя по умолчанию — 12345678;
- PIN-код администратора по умолчанию — 87654321. PIN-код администратора даёт право использовать дополнительные функции: разблокировка PIN-кода пользователя, настройка параметров PIN-кодов и др.
Рекомендуется сменить стандартный PIN-код на уникальный. Чтобы сделать это, выполните следующие действия:
- Подключите токен к компьютеру и откройте Панель управления Рутокен. В появившемся окне нажмите кнопку Ввести PIN-код… .
- Далее введите PIN-код токена по умолчанию для пользователя или администратора.
- После этого в блоке Управление PIN-кодами станет доступна кнопка Изменить… . Нажмите на неё.
- В появившемся окне укажите новый PIN-код. отображает степень надёжности PIN-кода. Подтвердите новый PIN-код и нажмите ОК.
Уязвимости токенов безопасности
Хотя токены безопасности предлагают пользователям и организациям множество преимуществ, они также могут иметь недостатки. Основным недостатком физических токенов безопасности является то, что они подвержены утере или краже. Например, токен безопасности может быть утерян во время путешествия или украден неавторизованной стороной. Если токен безопасности утерян или украден, его необходимо деактивировать и заменить. Тем временем неавторизованный пользователь, владеющий токеном, может получить доступ к конфиденциальной информации и системам.
Сергей Воробьёв
Интернет-предприниматель, специалист по SEO и SMM, E-commerce, вебмастер, блогер.
Разбираемся с взаимозаменяемостью
Во избежание потенциально возможных дилемм защиты, специалистам по ИТ-безопасности необходимо понимать, что же такое NFT. Концепция невзаимозаменяемых токенов не совсем проста. Большинство статей, посвященных NFT, в основном содержат околонаучную шумиху, а не простое, целостное определение NFT.
Сначала давайте разберемся с понятием «взаимозаменяемость». По определению Investopedia, «взаимозаменяемость — способность товара или актива легко обмениваться на аналогичный другой». Рассмотрим в качестве примера физическую валюту. Одну долларовую купюру можно легко обменять на другую без каких-либо последствий для владельцев. Хотя банкноты имеют разные серийные номера, функционально они одинаковы и по желанию могут быть обменены. Невзаимозаменяемые активы — даже если они похожи или почти идентичны — не взаимозаменяемы. Представьте две машины, развалюху после ДТП и новую, только что сошедшую с заводского конвейера. Машины вроде похожи, но не одинаковые, в данном случае обмен затронет обе стороны и будет совсем неравноценным.
В сфере цифровых платежей биткойны взаимозаменяемы. Хотя у них есть уникальные маркеры, один биткойн функционально идентичен другому. Между тем, NTF представляют собой уникальные цифровые активы. Люди не могут их дублировать или напрямую обмениваться с другими равноценными активами.
О паролях
Они стали классикой современности. Главное преимущество паролей, благодаря которому они так распространены, – это простота их использования. Но наша забывчивость, передача с использованием незащищенных каналов, их набор на клавиатуре, предсказуемость и много других аспектов ставят под сомнение нашу безопасность. Также остро состоит проблема шифрования. Давайте рассмотрим криптографический ключ на 256 бит. Если использовать генератор псевдослучайных чисел, то получившийся пароль будет обладать хорошими статистическими свойствами. А что собой представляют комбинации, которые выбирают для защиты своих данных люди? Во многих случаях пароли – это слова из словаря или что-то важное для них (их имя, дата рождения и прочее).
Достаточно только прочитать новости об очередном взломе базы данных крупного сайта или компании и посмотреть, какие комбинации выбирают себе люди. Очень часто здесь встречаются цифры, идущие подряд, начиная с единицы, или соединение имени и год рождения. Это, безусловно, очень плохо. Вот для таких случаев и предусмотрено использование токенов. Ведь они смогут защищать данные на высшем уровне с использованием рекомендованных параметров, когда просто подобрать пароль злоумышленникам будет сложно. Ведь код токена будет составлен по всем правилам криптографических протоколов. В качестве примера можно рассмотреть аутентификацию. Благодаря тому, что будет реализован принцип «любой из тысячи», даже если злоумышленником будет перехвачен трафик, или пропадёт база данных с сервера – шанс на успех у преступника настолько маловероятен, что его можно назвать несуществующим. К тому же, можно забыть пароль, но ключ – нет. Ведь он будет храниться на токене.
Структура JWT
Как показано на официальном сайте (с удобной песочницей), JWT состоит из трех частей, разделенных точкой:
- заголовок (красный)
- полезная нагрузка (фиолетовый)
- подпись (голубой)
Структура JWT
Заголовок и полезная нагрузка по сути передаются в открытом виде, хоть и выглядят как непонятные символы. Это формат base64, если вставить символы в любой онлайн-декодер, то получим исходник.
Вот третья часть — хеш, или подпись, как раз и является фишкой, гарантирующей подлинность токена. Из нее не получить «исходник», только наоборот: из исходника подпись можно получить. Что приложение и делает, именно так проверяется подлинность токена.
Составные части полезной нагрузки называются claims. Они могут быть registered (состоящими из 3 букв, например iat — «issued at»), public и private.
Общая картина
- Клиент вводит логин и пароль.
- Сервер проверяет их, и если они верны, высылает в ответе JWT-токен.
- Далее клиент высылает JWT-токен при каждом последующем запросе к серверу в заголовке Authorization
- Сервер проверяет JWT-токен на подлинность.
- И высылает ответ.
Картина в целом
Управление возможностями рынка NFT
NFT рынок уже начинает остывать. Средние цены за три недели упали более чем на 50% , также как и объемы продаж. Однако, маловероятно, что нефункционирующая структура полностью рухнет. Несмотря на внимание СМИ, NFT рынок за последний год стабильно рос. Скорее всего, он останется источником долгосрочной стоимости за счет масштабного удержания активов.
Cтремительный рост и падение NFT в сочетании с их устойчивым ценностным предложением означает, что предприятиям не стоит игнорировать данную угрозу безопасности. Естественно, вам следует помнить и о других угрозах.
Для надежной защиты активов компании придется дать отпор не только токенам.
Выучить больше
Серия видеороликов Learn Identity в документах Auth0 — это лекционная часть нового учебного курса по найму для инженеров в Auth0, представленного главным архитектором Витторио Берточчи. Если вы хотите лично узнать, как это делается в Auth0, она абсолютно бесплатна и доступна для всех.
Спецификации OAuth 2.0 и OpenID Connect являются сложными, но как только вы ознакомитесь с терминологией и получите базовые знания об идентификации, они будут полезны, информативны и станут намного более удобочитаемыми. Почитать их можно здесь: The OAuth 2.0 Authorization Framework и OpenID Connect Specifications..
JWT.io — это ресурс о JSON Web Token, который предоставляет инструмент отладчика и каталог библиотек подписи/проверки JWT для различных технологий.
OpenID Connect Playground — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы OIDC.
Ресурсы и что дальше?
Мы рассмотрели много материала, и даже не приблизились к рассмотрению всему что есть в области аутентификации и авторизации. Я надеюсь, что это была полезная статья по идентификации, авторизации и аутентификации.
В настоящее время я работаю над несколькими дополнительными постами в блоге, в которых более подробно рассматриваются веб-токены JSON, а также аутентификация и авторизация для приложений JavaScript.
Если вы хотите узнать больше, гораздо больше по этим темам, вот несколько полезных ресурсов для вас:
Можно ли узнать чужой код доступа?
Итак, вас интересует, как узнать токен другого человека, например, друга в ВК. Мы уже писали вначале, это невозможно. По крайней мере, законным или официальным путем. Данные сведения считаются закрытыми и надежно охраняются системой безопасности соцсети.
Если умеете взламывать, вперед! Но вы должны понимать, что идете на правонарушение. Со всеми вытекающими. В сети можно найти уйму способов узнать токен ВК другого человека, как рабочих, так и нет. Мы против неправомерных действий, а потому, ничего тут рекомендовать не станем. Упомянули же об этом лишь для полноты картины.
Другие функции
Кроме уже рассмотренных вариантов, это устройство может выполнять и другие задачи, которые поставлены перед ним. Среди них:
- Шифровка/дешифровка данных с использованием а/симметрического алгоритма.
- Формирование и проверка ЭЦП.
- Хеширование данных.
- Генерация ключей шифрования.
Для полноты образа токена его можно представить в виде «черного ящика». Так, при криптографических операциях данные поступают на вход, в самом устройстве преобразуются (для этого используется ключ) и передаются на выход. Токены имеют довольно много общего с микрокомпьютерами. Так, информация подаётся и выводится с использованием USB-порта, у устройства есть собственная оперативная и долговременная (к тому же ещё и защищенная) память, а также свой процессор.
Доступ к ресурсным API
Допустим, мы хотим использовать токен доступа для вызова API из одностраничного приложения. Как это выглядит?
Мы рассмотрели аутентификацию выше, поэтому давайте предположим, что пользователь вошел в наше приложение JS в браузере. Приложение отправляет запрос авторизации на сервер авторизации, запрашивая токен доступа для вызова API.
Затем, когда наше приложение хочет взаимодействовать с API, мы присоединяем токен доступа к заголовку запроса, например, так:
# HTTP заголовок запроса Authorization: ‘Bearer eyj[…]’
Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.
Это замечательно, но есть кое-что, что может произойти с вами прямо сейчас. Ранее мы заявляли, что OAuth решает проблемы с излишним доступом. Как это решается здесь?
