токен криптовалюты, ico токены, электронные жетоны, токен это

В одной из статей мы рассказали Вам об ICO, как этот процесс взаимосвязан с криптовалютами, стоит ли в них инвестировать и можно ли из этого получить конкретные benefits. Говоря о таком способе привлечения финансирования, мы постоянно сталкиваемся с таким понятием, как «токен», которое во многом определяет этот процесс. Поэтому ниже мы поговорим о токенах и разберемся, что же это такое.

Понятие токена

Термин «Токен» (жетон) имеет много различных определений, однако мы его будем рассматривать в качестве обозначения частного денежного знака (в классическом варианте – металлический). Первые токены чеканились купцами в Англии в XVII веке, которые использовали их для осуществления торговых сделок. Были также памятные, пропагандистские и представительские жетоны. В принципе, до настоящего времени в сфере финансов данное понятие употребляется в обиходе для обозначения «заменителя денег».

В мире криптовалют токенами называются электронные жетоны (проводим сравнение с аналогами из металла), которые выпускаются для решения следующих задач: продажа акций, кредитование и монетизация дополнительного сервиса для пользователей сети, кредитование, привлечения финансирования путем создания децентрализованных сетей и, соответственно, заменителей монет.

Выделяют три основных вида токенов:

• токены приложений;
• кредитные (долговые) токены;
• токены-акции.

Токены приложений

Основная цель токенов приложений – оплата внутренних сетевых сервисов конкретного проекта. Их наличие позволяет пользователю получить доступ к дополнительным функциям, возможностям в децентрализованной сети. Необходимо отметить, что такие жетоны и криптовалюта – две разные вещи. Например, пользователи сети Steemit получают токены за размещение контента, популяризацию либо создания новых фичей. В данном случае токен – реферальная награда. В экосистеме Биткоина и Эфириума их можно получить только посредством майнинга. Большинство токенов фигурируют в сети, тем самым их можно беспрепятственно приобретать, продавать и обменивать на иные криптовалюты. Также важным является то, что их оборот обычно регламентирован основным протоколом, но в отличие от цифровых валют, не так жестко.

Кредитные токены

Одной из основных функций электронных жетонов является инвестирование обычных денег (доллары, евро, юани и т.д.) в новые проекты, которые демонстрируют высокий показатель ликвидности. Например, приобретя кредитные токены Steem Dollar (SD), вы можете рассчитывать на доход в размере 10% годовых от общей суммы займа. При этом выплаты, согласно условиям, осуществляются в SD, несмотря на то, что платежи пользователей в основном производятся в фиатных деньгах. Таким образом, блокчейн система Steemit получает средства на свое развитие, а пользователи доходы. Для такой бизнес-модели наличие электронных жетонов и их оборот является определяющим моментом.

Токены-акции

Как мы уже упоминали в статье, посвященной ICO, практически ежедневно мы узнаем о новых стартапах, которые привлекают финансирование посредством выпуска собственных токенов, которые приобретаются любым лицом, кому интересен проект. Возникает логичный вопрос, почему не создать сразу новую криптовалюту? Дело в том, что у инициаторов стартапов нет возможности ждать определенное время, пока новая цифровая валюта укрепит свои позиции на рынке.

Несмотря на то, что такая модель является достаточно новой и не до конца регламентирована, она смогла продемонстрировать свою эффективность, что постоянно увеличивает ее популярность. В данном случае токены можно рассматривать в качестве аналога акций, но при этом не предусматривают последующих доходов их владельцам. В очень редких случаях электронные жетоны предполагают предоставление доли в бизнесе и право голоса держателям при рассмотрении инициатив развития проекта.

Эту и другие новости предлагаем Вам обсудить в нашей группе в Telegram — https://t.me/coinnetru. Став ее участником, вы всегда будете в курсе всех последних событий, происходящих в мире криптовалют.

Как создать токен за 5 минут? Рассказываем на примере платформы Enecuum

Для запуска токена на Ethereum нужно написать смарт-контракт. На EOS — купить оперативную память. Команда проекта Enecuum считает: выпуск токена не должен быть таким сложным. Задача Enecuum — упростить процесс до нескольких кликов мышкой.

Рассказываем, зачем нужны токены, и как их создавать в Ethereum, Tron, EOS и Enecuum. В конце материала выпускаем токен за пять минут.

Что такое токен

Токен — это цифровой актив на основе криптовалюты. Например, токен ERC20 — стандартный токен на платформе Ethereum.
Создатель (эмитент) задает название токенов, их эмиссию и комиссии за транзакции.

Учредитель Центра разработки блокчейн-решений для бизнеса Павел Кравченко выделяет такие функции токенов:

• средство учета в блокчейне;
• аналог акций;
• платежное средство.

Токены работают на блокчейне основной криптовалюты, для их хранения не нужен отдельный кошелек. Сложность создания токена, комиссии и скорость транзакций зависят от платформы.

Как создать токены на Ethereum, Tron, EOS и Enecuum

По данным Enecuum, существует 19 платформ для выпуска токенов. Разберем процесс создания токенов на Ethereum, TRON, EOS и Enecuum.

Сравнительная таблица: создание токена на Ethereum, EOS, Tron и Enecuum

Ethereum: пишем, компилируем, публикуем

1. Установите текстовый редактор Atom или SublimeText, чтобы удобно редактировать смарт-контракт.
2. Напишите код смарт-контракта или скачайте шаблон и поменяйте в нем название токена и эмиссию.
3. Переведите текст смарт-контракта в байтовый код.
4. Опубликуйте его через MyEtherWallet или Metamask.
5. Оплатите публикацию смарт-контракта: 320 000 GAS, это примерно $2 на момент публикации. Для публикации больших смарт-контрактов нужно больше GAS.

EOS: командная строка и клиент EOS Cleos

1. Установите клиент EOS Cleos через командную строку. Это сложно, если вы раньше не работали с консолью.
2. Купите оперативную память, чтобы сеть проводила транзакции токенов.
3. Напишите код смарт-контракта или создайте его через EZEOS.
4. Опубликуйте смарт-контракт через EOS Cleos.

TRON: стандартные и кастомные смарт-контракты для выпуска токенов

1. Зайдите на Tronscan.
2. Авторизуйтесь и выберите тип токена: TRC-10 на стандартном смарт-контракте или TRC-20 на кастомном смарт-контракте.
3. Заполните информацию о токене и подтвердите его создание.
4. Сайт внесет информацию о токене в шаблон смарт-контракта и опубликует ваш смарт-контракт в блокчейне. Так создали токен BitTorrent.
5. Если пишете смарт-контракт для токенов TRC-20, нужно вставить код смарт-контракта в форму и подтвердить публикацию.
6. TRC-10 сеть спишет с вашего кошелька 1024 TRX (примерно $18 на момент публикации по ХХХ).
7. Если не хотите платить, установите среду разработки TronBox и сами напишите смарт-контракт.

Enecuum: стандартный смарт-контракт для быстрого выпуска токена

1. Зайдите на сайт или авторизуйтесь в приложении.
2. Создайте кошелек и пополните его на 1000 ENQ ($13 на момент публикации)
3. Заполните форму: название, эмиссия и комиссия за транзакции токенов.
4. Сайт внесет информацию о токене в стандартный смарт-контракт и опубликует его в блокчейне.
5. За создание токена сеть спишет с вашего кошелька 1000 ENQ.

Процесс выпуска токена занимает 5 минут, но об этом ниже.

Почему Enecuum использует стандартные смарт-контракты для выпуска токенов

Разработчик без опыта может написать смарт-контракт с ошибками. Из-за такой ошибки хакер украл $50 млн в ETH из The DAO. Злоумышленник отправил на смарт-контракт токены и перезапустил контракт несколько раз перед завершением обмена. При каждом перезапуске смарт-контракт считал, что получил новые токены и еще раз отправлял ETH на кошелек хакера.

Смарт-контракт позволяет вывести монеты, если транзакцию подписывают большинство владельцев кошелька. Но чтобы изменить количество подписей для вывода средств в Ethereum, достаточно одной подписи. Так злоумышленник может уменьшить количество подписей до одной и вывести монеты без согласия остальных владельцев.

По этим причинам Enecuum ввели стандартный SHARNELL смарт-контракт для создания токенов. Преимущества стандартного смарт-контракта:

• пользователь не может изменить код смарт-контракта и создать уязвимость;
• SHARNELL использует линейную логику и простые операции, его легко проверить на ошибки;
• безопасность смарт-контракта проверят аудиторы. После этого Enecuum добавит его в основную сеть.

Как Enecuum решает проблему комиссий

В Ethereum за перевод токенов нужно платить комиссию в основной монете: чтобы отправить Tether USD на платформе Ethereum, нужно заплатить комиссию в ETH. Это проблема для пользователей.

Представьте, вы заработали $100. Но не можете купить буханку хлеба, потому что за любую операцию нужно заплатить комиссию в чилийских песо.

За транзакции нужно платить основной криптовалютой, потому что майнеры не принимают токены. Но в Enecuum работу майнеров оплачивает эмитент токена:

• во время создания токена эмитент платит комиссию 1000 ENQ;
• из этой комиссии майнеры получают оплату за обработку транзакций токенов;

Пользователи платят комиссии в токенах. Эмитент токена устанавливает фиксированный размер комиссии или процент от суммы. При этом он может назначить нулевую комиссию и сделать транзакции бесплатными для пользователей.

Как работает комиссия в Enecuum

Баланс смарт-контракта для оплаты комиссий можно только пополнить. Если создатель не хочет это делать, пополнить счет могут пользователи.

Какой протокол консенсуса у Enecuum

Сеть Enecuum работает на протоколе консенсуса Trinity. Этот протокол объединяет три алгоритма консенсуса:

• Proof of Activity: приложение Enecuum на смартфоне проверяет случайные транзакции и собирает их в микроблоки. Чтобы майнить, нужно иметь на кошельке от 25 ENQ;
• Proof of Stake: один из 100 крупнейших кошельков становится лидером сети. Он подтверждает транзакции в микроблоках, собирает их в макроблок и подписывает его ключом;
• Proof of Work: узлы Enecuum на компьютерах подтверждают макроблок и добавляют его в блокчейн.

Так пользователи Enecuum могут майнить на смартфонах.

Какие токены можно выпустить на Enecuum

Создатель токена настраивает его параметры: возможность майнинга и взаимозаменяемость.

Enecuum позволяет выпускать:

• взаимозаменяемые (fungible) токены — аналоги платежных средств;
• уникальные (non fungible) токены — идентификаторы предметов, криптовалютных адресов и подарочных карт.

Взаимозаменяемые токены могут быть майнинговыми (minable). Пользователи будут добывать такие токены на мобильных телефонах.

В настоящий момент Enecuum тестирует выпуск взаимозаменяемых токенов. Их применение ограничено вашей фантазией. Вот несколько идей:

• Внутренняя валюта. Запускаете децентрализованное приложение, в котором токен — средство оплаты. Пользователи рассчитываются этими токенами внутри приложения.
• Стейблкоины. Создаете токен, обеспеченный стабильным активом.
• Токены для ICO. Создаете токены, продаете их в рамках ICO. Токены могут выполнять функцию ключей доступа к вашему продукту или предоставлять скидку на оплату услуг.
• Средство учета. Выпускаете токен, проводите небольшую транзакцию, в комментарии к этому переводу указываете данные для записи. Эти данные попадают в блокчейн, их нельзя изменить.
• Средство голосования. Раздаете участникам голосования по токену, создаете два адреса: «За» и «Против». Пользователи делают выбор и отправляют токены на один из адресов.

Практика: выпускаем токен на Enecuum за 5 минут

Шаг первый. Зайдите в тестовую сеть bit.enecuum.com. Зарегистрируйте кошелек, запишите адрес и приватный ключ. Скопируйте публичный адрес кошелька.

Обязательно запишите адрес и ключ. Если закроете сайт, вы не сможете восстановить эти данные.

Шаг второй. Запросите на кошелек монеты BIT для запуска токена: нажмите кнопку «Получить монеты BIT», введите публичный адрес кошелька и кликните «Подтвердить».

Шаг третий. Перейдите в кошелек, нажмите кнопку «Создание токена». На этой странице укажите: название, тикер, эмиссию и комиссию токена. Кликните «Создание токена» и подтвердите.

Шаг четвертый и последний. Проверьте, появился ли токен в списке.

Бонус: переводим токены на другой кошелек

Мы создали токены. Проверим, можно ли их перевести, и заодно посмотрим, как работает комиссия.

Шаг первый. Перейдите в кошелек, выберите токен для отправки. Введите количество токенов и адрес получателя.

Шаг второй. Подтвердите транзакцию. Комиссия указана в токенах, а не в основной монете ENQ.

Шаг третий и последний. Получите токены.

Выводы

Enecuum планирует добавить создание токенов в основную сеть во втором квартале 2020 года. Компания упростила этот процесс и обезопасила пользователей от ошибок в смарт-контрактах.

Система комиссии Enecuum сделает токены более доступными для понимания и широкого применения. С вводом майнинговых и уникальных токенов пользователи получат простой инструмент для реализации большого количества идей.

Возможно, скоро супермаркеты будут начислять бонусы в токенах, а не в баллах на карту.

Подписывайтесь на новости ForkLog в Telegram: ForkLog Feed — вся лента новостей, ForkLog — самые важные новости и опросы.

Нашли ошибку в тексте? Выделите ее и нажмите CTRL+ENTER

Пять простых шагов для понимания JSON Web Tokens (JWT) / Хабр

Представляю вам мой довольно вольный перевод статьи 5 Easy Steps to Understanding JSON Web Tokens (JWT). В этой статье будет рассказано о том, что из себя представляют JSON Web Tokens (JWT) и с чем их едят. То есть какую роль они играют в проверке подлинности пользователя и обеспечении безопасности данных приложения.

Для начала рассмотрим формальное определение.

JSON Web Token (JWT) — это JSON объект, который определен в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д. и подписи (signature).
Кстати, правильно JWT произносится как /dʒɒt/

Простыми словами, JWT — это лишь строка в следующем формате header.payload.signature.
Предположим, что мы хотим зарегистрироваться на сайте. В нашем случае есть три участника — пользователь user, сервер приложения application server и сервер аутентификации authentication server. Сервер аутентификации будет обеспечивать пользователя токеном, с помощью которого он позднее сможет взаимодействовать с приложением.

Приложение использует JWT для проверки аутентификации пользователя следующим образом:

1. Сперва пользователь заходит на сервер аутентификации с помощью аутентификационного ключа (это может быть пара логин/пароль, либо Facebook ключ, либо Google ключ, либо ключ от другой учетки).
2. Затем сервер аутентификации создает JWT и отправляет его пользователю.
3. Когда пользователь делает запрос к API приложения, он добавляет к нему полученный ранее JWT.
4. Когда пользователь делает API запрос, приложение может проверить по переданному с запросом JWT является ли пользователь тем, за кого себя выдает. В этой схеме сервер приложения сконфигурирован так, что сможет проверить, является ли входящий JWT именно тем, что был создан сервером аутентификации (процесс проверки будет объяснен позже более детально).

Структура JWT

JWT состоит из трех частей: заголовок header, полезные данные payload и подпись signature. Давайте пройдемся по каждой из них.

Хедер JWT содержит информацию о том, как должна вычисляться JWT подпись. Хедер — это тоже JSON объект, который выглядит следующим образом:

header = { "alg": "HS256", "typ": "JWT"}

Поле typ не говорит нам ничего нового, только то, что это JSON Web Token. Интереснее здесь будет поле alg, которое определяет алгоритм хеширования. Он будет использоваться при создании подписи. HS256 — не что иное, как HMAC-SHA256, для его вычисления нужен лишь один секретный ключ (более подробно об этом в шаге 3). Еще может использоваться другой алгоритм RS256 — в отличие от предыдущего, он является ассиметричным и создает два ключа: публичный и приватный. С помощью приватного ключа создается подпись, а с помощью публичного только лишь проверяется подлинность подписи, поэтому нам не нужно беспокоиться о его безопасности.

Шаг 2. Создаем PAYLOAD

Payload — это полезные данные, которые хранятся внутри JWT. Эти данные также называют JWT-claims (заявки). В примере, который рассматриваем мы, сервер аутентификации создает JWT с информацией об id пользователя — userId.

payload = { "userId": "b08f86af-35da-48f2-8fab-cef3904660bd" }

Мы положили только одну заявку (claim) в payload. Вы можете положить столько заявок, сколько захотите. Существует список стандартных заявок для JWT payload — вот некоторые из них:

• iss (issuer) — определяет приложение, из которого отправляется токен.
• sub (subject) — определяет тему токена.
• exp (expiration time) — время жизни токена.

Эти поля могут быть полезными при создании JWT, но они не являются обязательными. Если хотите знать весь список доступных полей для JWT, можете заглянуть в Wiki. Но стоит помнить, что чем больше передается информации, тем больший получится в итоге сам JWT. Обычно с этим не бывает проблем, но все-таки это может негативно сказаться на производительности и вызвать задержки во взаимодействии с сервером.

Шаг 3. Создаем SIGNATURE

Подпись вычисляется с использование следующего псевдо-кода:

const SECRET_KEY = 'cAtwa1kkEy'
const unsignedToken = base64urlEncode(header) + '.' + base64urlEncode(payload)
const signature = HMAC-SHA256(unsignedToken, SECRET_KEY)

Алгоритм base64url кодирует хедер и payload, созданные на 1 и 2 шаге. Алгоритм соединяет закодированные строки через точку. Затем полученная строка хешируется алгоритмом, заданным в хедере на основе нашего секретного ключа.

// header eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
// payload eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ
// signature -xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Шаг 4. Теперь объединим все три JWT компонента вместе

Теперь, когда у нас есть все три составляющих, мы можем создать наш JWT. Это довольно просто, мы соединяем все полученные элементы в строку через точку.

const token = encodeBase64Url(header) + '.' + encodeBase64Url(payload) + '.' + encodeBase64Url(signature)
// JWT Token
// eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

Вы можете попробовать создать свой собственный JWT на сайте jwt.io.
Вернемся к нашему примеру. Теперь сервер аутентификации может слать пользователю JWT.

Как JWT защищает наши данные?

Очень важно понимать, что использование JWT НЕ скрывает и не маскирует данные автоматически. Причина, почему JWT используются — это проверка, что отправленные данные были действительно отправлены авторизованным источником. Как было продемонстрировано выше, данные внутри JWT закодированы и подписаны, обратите внимание, это не одно и тоже, что зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных. Таким образом закодирование и подпись данных не защищает их. С другой стороны, главная цель шифрования — это защита данных от неавторизованного доступа. Для более детального объяснения различия между кодированием и шифрованием, а также о том, как работает хеширование, смотрите эту статью. Поскольку JWT только лишь закодирована и подписана, и поскольку JWT не зашифрована, JWT не гарантирует никакой безопасности для чувствительных (sensitive) данных.

Шаг 5. Проверка JWT

В нашем простом примере из 3 участников мы используем JWT, который подписан с помощью HS256 алгоритма и только сервер аутентификации и сервер приложения знают секретный ключ. Сервер приложения получает секретный ключ от сервера аутентификации во время установки аутентификационных процессов. Поскольку приложение знает секретный ключ, когда пользователь делает API-запрос с приложенным к нему токеном, приложение может выполнить тот же алгоритм подписывания к JWT, что в шаге 3. Приложение может потом проверить эту подпись, сравнивая ее со своей собственной, вычисленной хешированием. Если подписи совпадают, значит JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки. Таким образом, проверяя JWT, приложение добавляет доверительный слой (a layer of trust) между собой и пользователем.

В заключение

Мы прошлись по тому, что такое JWT, как они создаются и как валидируются, каким образом они могут быть использованы для установления доверительных отношений между пользователем и приложением. Но это лишь кусочек пазла большой темы авторизации и обеспечения защиты вашего приложения. Мы рассмотрели лишь основы, но без них невозможно двигаться дальше.

Что дальше?

Подумаем о безопасности и добавим Refresh Token. Смотрите следующую мою статью на эту тему.

Полезные ссылки

1. 5 Easy Steps to Understanding JSON Web Tokens (JWT)
2. Securing React Redux Apps With JWT Tokens
3. Зачем нужен Refresh Token, если есть Access Token?

Что такое Security Token Offering (STO)? — Крипто на vc.ru

Что ждет ICO на одном из крупнейших мировых инвестиционных рынков — в США?

Читайте статью Нэйтана Родригеза, сооснователя Chainbits, человека с 20-летним опытом работы в сфере интернет-рекламы и интернет-маркетинга. Криптоэнтузиаст и инвестор, Нэйтан провел последние несколько лет изучая потенциал технологии блокчейн и криптовалют.

За последние два года блокчейн-стартапы собрали в ICO немалые суммы денег. В теории, модель ICO предлагает высокодоходное вложение как компаниям, так и частным лицам, которые хотят поддержать проект. Так, например, польза для компании состоит в том, что они предлагают свои токены в обмен на криптовалюту и при этом им не приходится продавать свои доли. В свою очередь, вкладчики могут поучаствовать в проекте, который он хотят поддержать. Купив токены, они могут использовать их внутри экосистемы или чтобы получить прибыль от перепродажи.

Эта модель стала популярным средством сбора финансов для многих предприятий на основе блокчейна, которые выпускают так называемые utility-токены — криптовалюты или койны, которые представляют собой средство получения доступа к товару или услуге компании. Одно из основных свойств таких utility-токенов в том, что они определенно не являются вложением непосредственно в компанию. Пользователи не получают во владение доли компании и, соответственно, не получают сопутствующих акционерных прав.

Utility-токены могут оказаться прибыльным вложением, однако по сути они представляют собой возможность оплатить сервис, который, может быть, пока не существует. Они могут сгодиться на перепродажу, но у них не может быть никакой долгосрочной ценности, пока выпустившая их компания не запустит свой сервис (момент, который в почти 50% ICO так и не наступает). Суть проблемы заключена в том, что за этими токенами не стоит никаких активов, которые придавали бы им ценности.

Однако, не так давно возникла новая парадигма токенов: security-токен.

Что такое security-токен?

В отличие от utility-токенов, security-токены привязаны к реальным ценным бумагам, которые представляют токенизированные активы. В отдельных случаях эти токены представляют собой реальный капитал в предприятии, то есть выполняют роль “цифровой доли”. Security-токен не обязательно привязан к доле в компании, их можно использовать для разделения на части права владельца по отношению к широкому спектру активов, от недвижимости до искусства. На самом деле они могут предоставлять держателю целый ряд прав. Это может быть владение долями, периодические дивиденды, приток финансов, оплата задолженности, право на голосование и многое другое. Все эти права закреплены смарт-контрактом, который и управляет токенами.

Важен тот факт, что, ввиду особенностей этих токенов, с правовой и нормативной перспектив к ним относятся совсем иначе. Их ценность подкреплена ценными бумагами, следовательно, security-токены считаются вложением. Кроме того, это значит, что на выпускающие их компании накладываются дополнительные регулятивные требования и требования к предоставлению отчетности.

Это особенно важное отличие для инвестиционных организаций, это поскольку предотвращает одну из самых больших проблем utility-токенов. Вкладчики не получают никакой компенсации от ICO, в случае, если проект провалится или команда попросту заберет их деньги и сбежит. Их токены не считаются “ценными бумагами” (хотя это может измениться в будущем), поэтому у компаний нет никаких обязательств по созданию выгодных условий для держателей их токенов. ICO представляют собой очень перспективную стратегию сбора средств, но проблемы с регламентированием сферы и с чисто функциональным предназначением utility-токенов, делают эту затею более выгодной для компаний-организаторов, чем для вкладчиков. Кроме того, это создает почву для различного рода мошеннических схем.

Зачем нужен Refresh Token, если есть Access Token? / Блог компании Voximplant / Хабр

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Зачем вообще нужны токены

При разработке приложений, общающихся с сервером, обычно вылезают следующие этапы:

1. Приложение разрабатывает один разработчик, нет ни идентификации, ни аутентификации, ни авторизации (кстати, рекомендую замечательную хабрастатью на эту тему от DataArt), запросы напрямую ходят к эндпоинтам сервера, разработчик счастлив.
2. Появляется второй разработчик, или тестировщик, или заказчик. Серверу становится важно знать, кто именно отправляет запрос. Добавляется шаг идентификации: простенькое окно «представьтесь» перед стартом приложения и крики «кто опять заходил под тремя единичками и все сломал?!?»
3. Когда команда чуток устанет от «кто заходил под тремя единичками», на backend запилят форму регистрации с логином-паролем, которая будет проверять на уникальность логина. В таком виде продукт и будет разрабатываться до первой бета версии.
4. В первой бета версии окажется, что сохранять пароль в plain text на устройстве — это как-то не очень безопасно. У сферического пользователя в вакууме один пароль от большинства сервисов, и очень не хочется быть крайним, через кого у пользователя взломали мейл, вконтактик и все остальное. Начинаются поиски решения «что бы такое сделать, чтобы пароль в явном виде не хранить». И через некоторое время команда приходит к тому или иному варианту «auth token».

Зачем нужен первый токен

Есть много разных токенов. Обычные, криптографические, «access key», «session token», разные схемы получения, использования и revoke. При этом одна из ключевых идей заключается в том, что если кто нехороший получит чужой токен, то самое неприятное, что случится — это доступ похитителя к сервису, от которого токен похищен. Пароль, тот самый, который один на все сервисы, похититель не получит. А пользователь, если поймет, что кроме него к сервису получил доступ кто-то другой, может токен отозвать. После чего получить себе новый, имея логин и пароль.

Зачем нужен второй токен

В OAuth 2 и некоторых других схемах авторизации (например, у нас) есть не один, а целых два токена. Первый, access token, используется при запросах к серверу (например, при логине). У него есть два свойства: он многоразовый и короткоживущий. Наш, к примеру, живет 48 часов, а у кого-то 30 минут. Время выбирается на основании того, как используется сервис. Второй, refresh token, используется для обновления пары access и refresh токенов. У него тоже есть два свойства, обратные первому токену: он одноразовый и долгоживущий. Совсем долгоживуший, наш живет месяц.

Схема использования у токенов следующая:

• Пользователь логинится в приложении, передавая логин и пароль на сервер. Они не сохраняются на устройстве, а сервер возвращает два токена и время их жизни
• Приложение сохраняет токены и использует access token для последующих запросов
• Когда время жизни access token подходит к концу (приложение может само проверять время жизни, или дождаться пока во время очередного использования сервер ответит «ой, всё»), приложение использует refresh token, чтобы обновить оба токена и продолжить использовать новый access token

Примерно так это все объяснено в документации OAuth, на Википедии, в нашей документации. И такое объяснение не отвечает на вопрос нафига?!? Зачем нужны два токена, если можно обойтись одним? В вопросе на stackoverflow даны несколько объяснений уровня «ну, access token можно менее надежно хранить чем refresh token и не бояться использовать вне HTTPS соединений. Например, хранить access token на frontend, а refresh token на backend» или «refresh token используется для доступа к заведомо безопасному сервису, а access token’ом потом можно тыкать во всякие подозрительные места и не очень бояться, что его сольют». Это может быть разумно для авторизации через Facebook и последующего использования без HTTPS. Но у нас-то везде HTTPS! И сервис у нас тоже один, наш. Зачем нам второй токен?

Зачем на самом деле нужен второй токен

Все оказалось и проще, и сложнее чем я думал. Следите за руками:

Случай 1: Боб узнал оба токена Алисы и не воспользовался refresh

В этом случае Боб получит доступ к сервису на время жизни access token. Как только оно истечет и приложение, которым пользуется Алиса, воспользуется refresh token, сервер вернет новую пару токенов, а те, что узнал Боб, превратятся в тыкву.

Случай 2: Боб узнал оба токена Алисы и воспользовался refresh

В этом случае оба токена Алисы превращаются в тыкву, приложение предлагает ей авторизоваться логином и паролем, сервер возвращает новую пару токенов, а те, что узнал Боб, снова превратятся в тыкву (тут есть нюанс с device id, может вернуть ту же пару что и у Боба. В таком случае следующее использование refresh токена превратит токены Боба в то, что изображено справа).

Таким образом, схема refresh + access токен ограничивает время, на которое атакующий может получить доступ к сервису. По сравнению с одним токеном, которым злоумышленник может пользоваться неделями и никто об этом не узнает.

Безопасность

— что такое аутентификация на основе токенов?

Переполнение стека

1. Около
2. Товары
3. Для команд

1. Переполнение стека Общественные вопросы и ответы
2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
5. Реклама Обратитесь к разработчикам и технологам со всего мира

.

oauth — что такое токен доступа по сравнению с секретом токена доступа и ключом потребителя по сравнению с секретом потребителя

Переполнение стека

1. Около
2. Товары
3. Для команд

1. Переполнение стека Общественные вопросы и ответы
2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
5. Реклама Обратитесь к разработчикам и технологам со всего мира
6. О компании

.

JSON Web Token Introduction — jwt.io

НОВИНКА: получите Справочник JWT бесплатно и подробно изучите JWT!

Что такое веб-токен JSON?

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эту информацию можно проверить и доверять, потому что она имеет цифровую подпись. JWT могут быть подписаны с использованием секрета (с алгоритмом HMAC ) или пары открытого / закрытого ключей с использованием RSA или ECDSA .

Хотя JWT могут быть зашифрованы для обеспечения секретности между сторонами, мы сосредоточимся на подписанных токенах. Подписанные токены могут проверять целостность утверждений, содержащихся в нем, в то время как зашифрованные токены скрывают эти утверждения от других сторон. Когда токены подписываются с использованием пар открытого / закрытого ключей, подпись также удостоверяет, что только сторона, владеющая закрытым ключом, является той, которая его подписала.

Когда следует использовать веб-токены JSON?

Вот несколько сценариев, в которых полезны веб-токены JSON:

• Авторизация : это наиболее распространенный сценарий использования JWT.После того, как пользователь вошел в систему, каждый последующий запрос будет включать JWT, позволяя пользователю получать доступ к маршрутам, службам и ресурсам, разрешенным с помощью этого токена. Единый вход в систему — это функция, которая в настоящее время широко использует JWT из-за ее небольших накладных расходов и ее способности легко использоваться в разных доменах.

• Обмен информацией : Веб-токены JSON — хороший способ безопасной передачи информации между сторонами. Поскольку JWT могут быть подписаны, например, с использованием пар открытого и закрытого ключей, вы можете быть уверены, что отправители являются теми, кем они себя называют.Кроме того, поскольку подпись рассчитывается с использованием заголовка и полезной нагрузки, вы также можете убедиться, что содержимое не было изменено.

Какова структура веб-токена JSON?

В компактной форме веб-токены JSON состоят из трех частей, разделенных точками (, ), а именно:

Следовательно, JWT обычно выглядит следующим образом.

xxxxx.yyyyy.zzzzz

Давайте разберем разные части.

Заголовок

Заголовок , как правило, состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.

Например:

  {
  "alg": "HS256",
  "тип": "JWT"
}
  

Тогда этот JSON имеет кодировку Base64Url для формирования первой части JWT.

Полезная нагрузка

Вторая часть токена — это полезная нагрузка, которая содержит утверждения. Утверждения — это утверждения о сущности (обычно, о пользователе) и дополнительных данных. Существует три типа требований: зарегистрированных , государственных и частных требований.

• Зарегистрированные претензии : это набор предопределенных претензий, которые не являются обязательными, но рекомендуются для предоставления набора полезных, совместимых претензий.Вот некоторые из них: iss (эмитент), exp (срок действия), sub (тема), aud (аудитория) и другие.

  Обратите внимание, что имена утверждений состоят всего из трех символов, поскольку JWT должен быть компактным.

• Публичные заявки : они могут быть определены по желанию теми, кто использует JWT. Но чтобы избежать коллизий, они должны быть определены в реестре веб-токенов IANA JSON или быть определены как URI, содержащий пространство имен, устойчивое к коллизиям.

• Частные претензии : Это настраиваемые претензии, созданные для обмена информацией между сторонами, которые соглашаются их использовать, и не являются ни зарегистрированными , ни публичными претензиями .

Пример полезной нагрузки может быть:

  {
  "sub": "1234567890",
  "name": "Джон Доу",
  "admin": правда
}
  

В этом случае полезная нагрузка представляет собой кодировку Base64Url для формирования второй части веб-токена JSON.

Обратите внимание, что для подписанных токенов эта информация, хотя и защищена от подделки, доступна для чтения кем угодно.Не помещайте секретную информацию в элементы полезной нагрузки или заголовка JWT, если она не зашифрована.

Подпись

Для создания части подписи вы должны взять закодированный заголовок, закодированные полезные данные, секрет, алгоритм, указанный в заголовке, и подписать его.

Например, если вы хотите использовать алгоритм HMAC SHA256, подпись будет создана следующим образом:

  HMACSHA256 (
  base64UrlEncode (заголовок) + "." +
  base64UrlEncode (полезная нагрузка),
  секрет)
  

Подпись используется для проверки того, что сообщение не было изменено в процессе, и в случае токенов, подписанных с помощью закрытого ключа, она также может проверить, что отправитель JWT является тем, кем он является.

Собираем все вместе

Результатом являются три строки URL-адреса Base64, разделенные точками, которые можно легко передавать в средах HTML и HTTP, но при этом они более компактны по сравнению со стандартами на основе XML, такими как SAML.

Ниже показан JWT, в котором закодированы предыдущий заголовок и полезная нагрузка, и он подписан секретом.

Если вы хотите поиграть с JWT и применить эти концепции на практике, вы можете использовать jwt.io Debugger для декодирования, проверки и генерации JWT.

Как работают веб-токены JSON?

При аутентификации, когда пользователь успешно входит в систему, используя свои учетные данные, будет возвращен веб-токен JSON. Поскольку токены являются учетными данными, необходимо проявлять большую осторожность, чтобы предотвратить проблемы с безопасностью. В общем, вы не должны хранить токены дольше, чем требуется.

Вы также не должны хранить конфиденциальные данные сеанса в хранилище браузера из-за недостаточной безопасности.

Когда пользователь хочет получить доступ к защищенному маршруту или ресурсу, пользовательский агент должен отправить JWT, обычно в заголовке Authorization , используя схему Bearer .Содержание заголовка должно выглядеть следующим образом:

  Авторизация: предъявитель <токен>
  

В некоторых случаях это может быть механизм авторизации без сохранения состояния. Защищенные маршруты сервера будут проверять наличие действительного JWT в заголовке Authorization , и если он присутствует, пользователю будет разрешен доступ к защищенным ресурсам. Если JWT содержит необходимые данные, потребность в запросе базы данных для определенных операций может быть уменьшена, хотя это не всегда так.

Если токен отправляется в заголовке Authorization , совместное использование ресурсов между источниками (CORS) не будет проблемой, поскольку оно не использует файлы cookie.

На следующей диаграмме показано, как JWT получается и используется для доступа к API или ресурсам:

1. Приложение или клиент запрашивает авторизацию у сервера авторизации. Это выполняется через один из разных потоков авторизации. Например, типичное веб-приложение, совместимое с OpenID Connect, будет проходить через конечную точку / oauth / authorize с использованием потока кода авторизации.
2. Когда авторизация предоставлена, сервер авторизации возвращает токен доступа приложению.
3. Приложение использует токен доступа для доступа к защищенному ресурсу (например, API).

Обратите внимание, что с подписанными токенами вся информация, содержащаяся в токене, предоставляется пользователям или другим сторонам, даже если они не могут ее изменить. Это означает, что вы не должны помещать секретную информацию в токен.

Почему мы должны использовать веб-токены JSON?

Давайте поговорим о преимуществах JSON Web Tokens (JWT) по сравнению с Simple Web Tokens (SWT) и Security Assertion Markup Language Tokens (SAML) .

Поскольку JSON менее подробен, чем XML, при кодировании его размер также меньше, что делает JWT более компактным, чем SAML. Это делает JWT хорошим выбором для передачи в средах HTML и HTTP.

С точки зрения безопасности, SWT может быть симметрично подписан общим секретом только с использованием алгоритма HMAC. Однако токены JWT и SAML могут использовать для подписи пару открытого / закрытого ключей в форме сертификата X.509. Подписание XML с помощью цифровой подписи XML без появления скрытых дыр в безопасности очень сложно по сравнению с простотой подписания JSON.

Парсеры

JSON распространены в большинстве языков программирования, поскольку они отображаются непосредственно на объекты. И наоборот, XML не имеет естественного преобразования документа в объект. Это упрощает работу с JWT, чем с утверждениями SAML.

Что касается использования, JWT используется в масштабе Интернета. Это подчеркивает простоту обработки веб-токена JSON на стороне клиента на нескольких платформах, особенно на мобильных.

Сравнение длины закодированного JWT и закодированного SAML

Если вы хотите узнать больше о веб-токенах JSON и даже начать использовать их для аутентификации в своих приложениях, перейдите на целевую страницу веб-токенов JSON по адресу Auth0.

.

Что такое токен ERC20? — Центр поддержки Blockchain

23 августа 2020 г. 18:30

• Что такое токен ERC20?
• Токен ERC20 — это актив на основе блокчейна с аналогичной функциональностью с биткойнами, эфиром и биткойнами: он может хранить стоимость, а также быть отправленным и полученным.
• Основное различие между токенами ERC20 и другими криптовалютами заключается в том, что токены ERC20 создаются и размещаются в цепочке блоков Ethereum, тогда как биткойны и биткойн-наличные являются собственными валютами соответствующих цепочек блоков.
• токенов ERC20 хранятся и отправляются с использованием адресов и транзакций Ethereum, а также используют газ для покрытия комиссий за транзакции.

• Почему ERC20?
• ERC20 — это официальный протокол для улучшения сети Ethereum (ETH).ERC расшифровывается как Ethereum Request for Comment, а 20 — это идентификатор предложения. Это общий стандарт для создания токенов в блокчейне Ethereum.
• Этот стандарт токенов определяет набор правил, которые применяются ко всем токенам ERC20, которые позволяют им беспрепятственно взаимодействовать друг с другом.
Кошельки и биржи
• используют стандарт для интеграции различных токенов ERC20 на свои платформы и упрощения обмена между токенами ERC20 и другими криптовалютами.

Была ли эта статья полезной? 53 из 56 нашли это полезным Остались вопросы? Отправить запрос

Комментарии

Статья закрыта для комментариев.

Статьи по теме

.